DAG: Directed Acyclic Graph
FSM: Functional Size Measurement
INCOSE: International Council on Systems Engineering
SADT: Structured Analysis and Design Technique
UML: Unified Modeling Language
The Software Requirements Knowledge Area (KA) is concerned with the elicitation, analysis, specification, and validation of software requirements. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.
The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, and Software Quality KAs.
1. Software Requirements Fundamentals
1.1. Definition of a Software Requirement
At its most basic, a software requirement is a property which must be exhibited in order to solve some problem in the real world. The Guide refers to requirements on “software” because it is concerned with problems to be addressed by software. Hence, a software requirement is a property which must be exhibited by software developed or adapted to solve a particular problem. The problem may be to automate part of a task of someone who will use the software, to support the business processes of the organization that has commissioned the software, to correct shortcomings of existing software, to control a device, and many more. The functioning of users, business processes, and devices is typically complex. By extension, therefore, the requirements on particular software are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.
1.2. Product and Process Requirements
A distinction can be drawn between product parameters and process parameters. Product parameters are
requirements on software to be developed. A process parameter is essentially a constraint on the
development of the software. These are sometimes known as process requirements.
1.3. Functional and Nonfunctional Requirements
Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.
Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are
sometimes known as constraints or quality requirements. They can be further classified according to whether they are performance requirements, maintainability requirements, safety requirements, reliability requirements, or one of many other types of software requirements.
1.4. Emergent Properties
Some requirements represent emergent properties of software—that is, requirements which cannot be
addressed by a single component, but which depend for their satisfaction on how all the software components
interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture.
1.5. Quantifiable Requirements
Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate,
quantitatively. It is important to avoid vague and unverifiable requirements which depend for their interpretation on subjective judgment. This is particularly important for nonfunctional requirements. The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture.
1.6. System Requirements and Software Requirements
In this topic, system means “an interacting combination of elements to accomplish a defined objective. These
include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements,” as defined by the International Council on Systems Engineering (INCOSE). System requirements are the requirements for the system as a whole. In a system containing software components, software requirements are derived from system requirements.
2. Requirements Process
2.1. Process Models
The objective of this topic is to provide an understanding that the requirements process.
Is not a discrete front-end activity of the software life cycle, but rather a process initiated at the beginning of a project and continuing to be refined throughout the life cycle.
Identifies software requirements as configuration items, and manages them using the same software configuration management practices as other products of the software life cycle processes.
Needs to be adapted to the organization and project context.
In particular, the topic is concerned with how the activities of elicitation, analysis, specification, and validation are configured for different types of projects and constraints. The topic also includes activities which provide input into the requirements process, such as marketing and feasibility studies.
2.2. Process Actors
This topic introduces the roles of the people who participate in the requirements process. This process is fundamentally interdisciplinary, and the requirements specialist needs to mediate between the domain of the stakeholder and that of software engineering. There are often many people involved besides the requirements specialist, each of whom has a stake in the software. The stakeholders will vary across projects, but always include users/operators and customers (who need not be the same).
2.3. Process Support and Management
This topic introduces the project management resources required and consumed by the requirements process. It establishes the context for the first subarea (Initiation and scope definition) of the Software Engineering Management KA. Its principal purpose is to make the link between the process activities identified in 2.1 and the issues of cost, human resources, training, and tools.
2.4. Process Quality and Improvement
This topic is concerned with the assessment of the quality and improvement of the requirements process. Its purpose is to emphasize the key role the requirements process plays in terms of the cost and timeliness of a software product, and of the customer’s satisfaction with it. It will help to orient the requirements process
with quality standards and process improvement models for software and systems. Process quality and improvement is closely related to both the Software Quality KA and the Software Engineering Process KA. Of particular interest are issues of software quality attributes and measurement, and software process definition. This topic covers:
- Requirements process coverage by process improvement standards and models
- Requirements process measures and benchmarking
- Improvement planning and implementation
3. Requirements Elicitation
Requirements elicitation is concerned with where software requirements come from and how the software engineer can collect them. It is the first stage in building an understanding of the problem the software is required to solve. It is fundamentally a human activity, and is where the stakeholders are identified and relationships established between the development team and the customer. It is variously termed “requirements capture,” “requirements discovery,” and “requirements acquisition.”
One of the fundamental tenets of good software engineering is that there be good communication between
software users and software engineers. Before development begins, requirements specialists may form the conduit for this communication. They must mediate between the domain of the software users (and other stakeholders) and the technical world of the software engineer.
3.1. Requirements Sources
Requirements have many sources in typical software, and it is essential that all potential sources be identified and evaluated for their impact on it. This topic is designed to promote awareness of the various sources of software requirements and of the frameworks for managing them.
The main points covered are Goals, Domain knowledge, Stakeholders, The operational environment, The organizational environment.
3.2. Elicitation Techniques
Once the requirements sources have been identified, the software engineer can start eliciting requirements from them. This topic concentrates on techniques for getting human stakeholders to articulate their requirements. It is a very difficult area and the software engineer needs to be sensitized to the fact that (for example) users may have difficulty describing their tasks, may leave important information unstated, or may be unwilling or unable to cooperate. It is particularly important to understand that elicitation is not a passive activity, and that, even if cooperative and articulate stakeholders are available, the software engineer has to work hard to elicit the right information. A number of techniques exist for doing this, the principal ones being.
Interviews, Scenarios, Prototypes, Facilitated meetings, Observation.
4. Requirements Analysis
This topic is concerned with the process of analyzing requirements to:
- Detect and resolve conflicts between requirements
- Discover the bounds of the software and how it must interact with its environment
- Elaborate system requirements to derive software requirements
4.1. Requirements Classification
- Whether the requirement is functional or nonfunctional
- Whether the requirement is derived from one or more high-level requirements or an emergent property or is being imposed directly on the software by a stakeholder or some other source.
- Whether the requirement is on the product or the process. Requirements on the process can constrain the choice of contractor, the software engineering process to be adopted, or the standards to be adhered to.
- The requirement priority. In general, the higher the priority, the more essential the requirement is for meeting the overall goals of the software. Often classified on a fixed-point scale such as mandatory, highly desirable, desirable, or optional, the priority often has to be balanced against the cost of development and implementation.
- The scope of the requirement. Scope refers to the extent to which a requirement affects the software and software components. Some requirements, particularly certain nonfunctional ones, have a global scope in that their satisfaction cannot be allocated to a discrete component. Hence, a requirement with global scope may strongly affect the software architecture and the design of many components, whereas one with a narrow scope may offer a number of design choices and have little impact on the satisfaction of other requirements.
- Volatility/stability. Some requirements will change during the life cycle of the software, and even during the development process itself. It is useful if some estimate of the likelihood that a requirement change can be made. For example, in a banking application, requirements for functions to calculate and credit interest to customers’ accounts are likely to be more stable than a requirement to support a particular kind of tax-free account. The former reflect a fundamental feature of the banking domain (that accounts can earn interest), while the latter may be rendered obsolete by a change to government legislation. Flagging potentially volatile
requirements can help the software engineer establish a design which is more tolerant of change.
4.2. Conceptual Modeling
The development of models of a real-world problem is key to software requirements analysis. Their purpose is to aid in understanding the problem, rather than to initiate design of the solution. Hence, conceptual models
comprise models of entities from the problem domain configured to reflect their real-world relationships and
dependencies. Several kinds of models can be developed. These include data and control flows, state models, event traces, user interactions, object models, data models, and many others. The factors that influence the choice of model include:
- The nature of the problem. Some types of software demand that certain aspects be analyzed particularly
rigorously. For example, control flow and state models are likely to be more important for real-time software
than for management information software, while it would usually be the opposite for data models.
- The expertise of the software engineer. It is often more productive to adopt a modeling notation or method with which the software engineer has experience.
- The process requirements of the customer. Customers may impose their favored notation or method, or prohibit any with which they are unfamiliar. This factor can conflict with the previous factor.
- The availability of methods and tools. Notations or methods which are poorly supported by training and
tools may not achieve widespread acceptance even if they are suited to particular types of problems.
4.3. Architectural Design and Requirements Allocation
At some point, the architecture of the solution must be derived. Architectural design is the point at which the
requirements process overlaps with software or systems design and illustrates how impossible it is to cleanly
decouple the two tasks. This topic is closely related to the Software Structure and Architecture subarea in the Software Design KA. In many cases, the software engineer acts as software architect because the process of
analyzing and elaborating the requirements demands that the components that will be responsible for satisfying the requirements be identified. This is requirements allocation–the assignment, to components, of the responsibility for satisfying requirements.
Architectural design is closely identified with conceptual modeling. The mapping from real-world domain entities to software components is not always obvious, so architectural design is identified as a separate topic. The requirements of notations and methods are broadly the same for both conceptual modeling and architectural design.
4.4. Requirements Negotiation
Another term commonly used for this sub-topic is “conflict resolution.” This concerns resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, between requirements and resources, or between functional and non-functional requirements, for example.
In most cases, it is unwise for the software engineer to make a unilateral decision, and so it becomes necessary to consult with the stakeholder(s) to reach a consensus on an appropriate trade-off. It is often
important for contractual reasons that such decisions be traceable back to the customer. We have classified this as a software requirements analysis topic because problems emerge as the result of analysis. However, a strong case can also be made for considering it a requirements validation topic.
No hay comentarios:
Publicar un comentario