Requirement
- Requirement
- an established need justifying the timely allocation of resources to develop a capability
to achieve approved goals or accomplish approved missions or tasks
As illustrated in the preceding figure, requirements are part of the following inheritance hierarchy:
The typically responsibilities of a requirement are to:
- Specify (depending on the type of requirement) a mandatory:
- functional behavior
- datum or data type
- quality factor or quality subfactor
- interface
- constraint on the architecture, design, or implementation.
- Upon implementation, requirements will help enable:
- The customer organization’s business
enterprise
to achieve some of its business goals.
- Members of the user organization(s) to better perform their tasks.
- Requirements form part of the basis for:
- Understanding the required nature of a business, system, component, or application domain.
- Estimating the associated:
- Size and complexity.
- Development effort and schedule.
- The architectures, designs, and implementation.
- Validation testing.
- Customer acceptance.
- Settling potential legal disputes regarding the success
of the endeavor between the customer organization and the
development organization.
Each individual requirement typically consists of:
- A formal statement of the requirement.
- Validation criteria for determining if the requirement is met.
- Attributes:
- Unique Identifier (for requirements identification and traceability).
- Categorization (e.g., data requirement, external API
requirement, functional requirement, quality requirement, constraint)
- Criticality to Customer (e.g., critical, high, medium, low)
- Criticality to Users (e.g., critical, high, medium, low)
- Estimated Cost Range (e.g., high, medium, low)
- Frequency of Execution (e.g., high, medium, low - if functional requirement)
- Implementation Status (e.g., not implemented, implemented)
- Justification (i.e., rationale)
- Owners (e.g., owning producer for implementation)
- Prioritization (e.g., current release, next release, eventually)
- Probability of Defects (in the implementation)
- Risk (associated with implementation) (e.g., high, medium, low)
- Source (i.e., requirements trace to document, goal, stakeholder)
- Status (e.g., Proposed, Analyzed, Specified, Evaluated, Approved, Baselined, Frozen, Retired)
- Stakeholders (i.e., requirements trace to stakeholder)
- Validation Method (e.g., analysis, demonstration, inspection, testing)
- Validation Status (e.g., not validated, validated)
- Volitility (e.g., high, medium, low)
- Part of a Requirements Diagram
- Part of a Requirements Model
Nevertheless, the typical contents of a requirement vary according to the:
- Requirement type.
- Requirements analysis (i.e., modeling) approach or technique.
- Requirements specification approach.
The typical stakeholders of a requirement are:
- Producers:
- Evaluators:
- Approvers:
- Maintainers:
- Users:
- Requirements Team,
which uses the requirements as input to the deliverable requirements specifications and other documents.
- Architecture Team,
which uses them to drive and validate the system architectures.
- Customer Organization,
which uses them to understand the scope of the application to be delivered.
- Hardware Development Team,
which uses them to drive the design of the hardware components.
- Independent Test Team,
which uses them to generate system and launch test cases.
- Metrics Team,
which uses them to estimate the size and scope of the endeavor.
- Project Management Team,
which uses them to manage project scope and schedule project activities.
- Software Development Team,
which uses them to drive the design of the software components.
- Subcontractor Organizations,
which use them to drive their work.
- User Experience Team,
which uses them to drive and validate the human interface prototype.
- User Support Team,
which uses them as input to the users manual and user support materials.
Requirements are typically produced during the following phases:
Requirements typically can be started if the following preconditions hold:
- Business Requirements:
- System, Application, Application Domain, or Component Requirements:
The typical inputs to a requirement include:
- Work Products:
- Stakeholders:
Requirements are typically constrained by the following conventions:
- Requirements Checklist
- Requirements engineering guidelines.
- Requirements specification content and format standards.
- Requirements specification templates.
- Requirements formally specify a mandatory,
externally-observable, and validatable (e.g., testable) aspect
of a business enterprise, system, application, component, or application domain
- Requirements are capabilities that are needed by the
customer and
user organizations
to achieve their objectives
(e.g., the required capabilities will enable users to better
perform their current tasks, enable users to perform new tasks,
or perform tasks that users cannot perform themselves).
Requirements are also capabilities that are formally imposed
(e.g., in a contract, statement of work, requirements
specification, standard, etc.) by the customer organization
onto the development organization.
- The above definition of requirements capture those
requirements that are within the scope of requirements
engineering. Other “requirements” include:
- Service Requirements.
Specifications of associated services that shall be
provided (e.g., user training, operations, maintenance, user support).
- Process Requirements.
Specifications of constraints on the development
process (e.g., how tasks shall be performed, development
cycles and milestones to be used, etc.).
- Management Requirements.
Specifications of constraints on cost, schedule,
development resources, etc.
- Guidance.
Specification of desires that are not mandatory (i.e., not actually required).
- The quality of the requirements is critical because they
drive all other activities and small defects in requirements
tend to have large negative impacts on overall productivity and development time.
- Requirements typically do not map one-to-one to
architecture, design, or implementation packages or modules.
- Except for trivial applications or components, it is
impossible to elicit, analyze, and specify all of the
requirements prior to the start of architecting, design, and implementation.
- Requirements are highly dynamic, due to changes in the
market place, the business enterprise, technology, laws and regulations, etc.
- Requirements exist because:
- A major stakeholder wants the business enterprise,
application, component, or center to meet the requirement.
- The business enterprise, application, component, or
center needs certain behaviors or qualities to be useful.
- Requirements Attributes:
- Requirements attributes are developed incrementally
and iteratively as the requirements are better understood.
- The large number of requirements attributes imply the
need for requirements engineering tools that are based on
a database with a single object/record per requirement.
- Requirements vs. Architecture, Design, and Implementation.
- Real World vs. Technology.
The new business, application, or component being
specified by the requirements will exist in order to help
certain groups of people to perform certain tasks (or
enable them to perform new ones) and thereby help them to
achieve certain goal(s). These people exist in the real
world, and the tasks they need help with also exist in
the real-world, typically in some domain such as
avionics, banking, finance, manufacturing, medicine,
travel, etc. In order to fulfil its purpose, the
requirements of the business, application, or component
should be specified in terms of the real world concepts
of these domains, and requirements engineers must first
understand the domain and the users needs before they
specify the requirements for something that will exist in the domain and help the users.
Although technology has a big influence on what is
feasible to specify, technology is a ‘how’
that rapidly evolves and will constantly enable new ways
of doing things. Therefore, the requirements for a
blackbox business, application, or component should be
specified in terms of the real world of the business
(i.e., the application domain) in which it will exist
instead of the technology that will be used to build its
internal components. Requirements engineers should let
the architects select the best available technology for
meeting the requirements, and not tie their hands by specifying it for them.
- Black-Box.
In order to minimize unnecessary restrictions
(i.e., constraints) on the architecture, design, and
implementation, requirements should treat the blackbox
business, application, or component being specified as a
black-box and, to the extent practical, they should ignore its internals.
- What vs. How.
Thus, requirements should specify
WHAT the business, application, or
component must be and do. They should leave it to the
architecture, design, and implementation to capture
HOW it will do what it does.
- Requirements Specifications.
Each requirements specification (i.e., cohesive collection of specified requirements) should be:
- Correct.
Contain only correct information including requirements.
- Complete.
Contain all required sections, paragraphs, and and
sufficient requirements to meet the goals of the stakeholders.
- Cohesive.
Contain only information that is related to its purpose.
- Consistent.
Consistent both internally and externally with other specifications.
- Extensible.
Can be extended as new requirements are identified, analyzed, and specified.
- Logically Organized.
Organized so that its contents can be easily located.
- Maintainable.
As requirements change.
- Minimal.
Contain no redundant or unnecessary information.
- Relatively Stable.
Requiring few changes by the start of the
construction phase.
- Understandable.
Easily understandable by members of its intended audiences.
- All types of requirements should be addressed. Too often,
all of the requirements engineering training and effort go
into the functional requirements, leaving the other
requirements underanalyzed and underspecified.
- A complete specification of a non-trivial
application may include from 1,000 to 500,000 individual
requirements (although it may only have 50 to 300 use cases).
- The complete collection of requirements form the scope of
the associated endeavor. The complete collection of all
requirements to be implemented for the current version of an
application form the scope of that release of the
applicaiton. Add requirements and the scope increases,
whereas remove requirements and the scope decreases.
- If you don’t know where you are going, how do you
know when you get there? The requirements state the goal.
Architecture, design, implementation, etc. provide the paths to get there.
Requirement is an abstract class of method components.
Examples of the different types of requirements are located with the associated method components:
