The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
The purpose of Requirements Management (REQM) is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.
This process area describes three types of requirements:
–product requirements, and
–product component requirements.
Taken together, these requirements address the needs of relevant stakeholders, including those pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., safety, reliability, and maintainability).
•Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products).
All development projects have requirements.
Requirements are the basis for design.
The development of requirements includes the following activities:
–Elicitation, analysis, validation, and communication of customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders
–Collection and coordination of stakeholder needs
–Development of the lifecycle requirements of the product
–Establishment of the customer requirements
–Establishment of initial product and product component requirements consistent with customer requirements
This process area addresses all customer requirements rather than only product-level requirements because the customer may also provide specific design requirements.
Develop the Customer Requirements
–Translate customer needs
–Define constraints for validation
Develop Product Requirements
–Establish Product and Product Component Requirements
–Allocate Product Component Requirements
–Identify Interface Requirements
Analyzeand Validate Requirements
–Establish operational concepts
FURPS+ A System for ClassifyingRequirements
A classification system was devised by Robert Grady at Hewlett-Packard.It goes by the acronym FURPS+ which represents:
The “+” in FURPS+ also helps us to remember concerns such as:
These requirements generally represent the main product features.
They state what the product must do.
Functional requirements are defined in general terms at the beginning of a project.
As the development progresses, requirements become better understood by all stakeholders.
Therefore, the requirements can be revised and improved in an iterative and incremental fashion.
•Usability, Reliability, Performance, and Supportability Requirements
•Non-functional requirements specify the Quality factors which determine the architecture in which the functional requirements are satisfied.
•The remaining “URPS” categories describe non-functional requirements that are generally architecturally significant.
•Usabilityis concerned with characteristics such as aesthetics and consistency in the user interface.
•Reliabilityis concerned with characteristics such as availability (the amount of system “up time”), accuracy of system calculations, and the system’s ability to recover from failure.
•Performanceis concerned with characteristics such as throughput, response time, recovery time, start-up time, and shutdown time.
•Supportabilityis concerned with characteristics such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability.
•Design, Implementation, Interface, and Physical Requirements
•The “+” in the FURPS+ acronym is used to identify additional categories that generally represent constraints.
•Adesign requirement, often called a design constraint, specifies or constrains the options for designing a system.
•Animplementation requirementspecifies or constrains the coding or construction of a system. Examples might include required standards, implementation languages, and resource limits.
•Aninterface requirementspecifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction.
•Aphysical requirementspecifies a physical constraint imposed on the hardware used to house the system Â—shape, size, or weight, for example.
•Capability Maturity Model Integration (CMMi) http://www.software-quality-assurance.org/index.htm