Requirement

Definition

Requirement

an established need justifying the timely allocation of resources to develop a capability to achieve approved goals or accomplish approved missions or tasks

Classification

As illustrated in the preceding figure, requirements are part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Work Product
• Subclasses:
  • Functional Requirement
  • Data Requirement
  • Quality Requirement
  • Interface Requirement
  • Constraint

Responsibilities

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.

Contents

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.

Stakeholders

The typical stakeholders of a requirement are:

• Producers:
  • Business Strategy Team (for business requirements).
  • Requirements Team (for application, application domain, and component requirements).
• Evaluators:
  • Strategy Evaluation Team (for business requirements).
  • Requirements Evaluation Team (for application, application domain, and component requirements).
• Approvers:
  • Project Manager
  • Technical Leader
  • Customer Representative
• Maintainers:
  • Business Strategy Team (for business requirements prior to delivery).
  • Customer Organization (for business requirements after delivery).
  • Requirements Team (for system, application, application domain, and component requirements prior to delivery).
  • Maintenance Team (for system, application, application domain, and component requirements after delivery).
• 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.

Phases

Requirements are typically produced during the following phases:

• Business Strategy: Business requirements completed.
• Business Optimization: Business requirements maintained
• Initiation: System or component requirements 80% completed.
• Construction: System or component requirements completed
• Initial Production: System or component requirements completed
• Full-Scale Production: System or component requirements completed
• Delivery: System or component requirements maintained
• Usage: System or component requirements maintained
• Retirement: System or component requirements deleted or archived

Preconditions

Requirements typically can be started if the following preconditions hold:

• Business Requirements:
  • The business strategy phase has started.
  • The business strategy team is staffed and trained in requirements engineering.
• System, Application, Application Domain, or Component Requirements:
  • The initiation phase has started.
  • The requirements team is staffed and trained in requirements engineering.
  • An initial version of the application vision statement is available.
  • The glossary is started.
  • Domain experts are available.

Inputs

The typical inputs to a requirement include:

• Work Products:
  • Application Vision Statement
  • Business Rules Catalog
  • Customer Analysis
  • Market Analysis
  • Technology Analysis
  • User Analysis
  • Domain Model Document
  • Problem Reports (from previous similar systems)
  • Customer Organization documents
  • Organizational policies
  • Industry analyst reports and white papers
  • Domain knowledge
  • Laws and regulations
  • Lists of goals
  • Reusable requirements and associated specifications
  • Industry standards or vendor organization documents (e.g., for standard APIs)
• Stakeholders:
  • Customer Organization
  • Development Organization and Industry Domain Experts (e.g., industry analysts)
  • Maintenance Organization
  • Marketing Organization
  • Support Organization
  • Vendor Organization

Conventions

Requirements are typically constrained by the following conventions:

• Requirements Checklist
• Requirements engineering guidelines.
• Requirements specification content and format standards.
• Requirements specification templates.

Guidelines

• 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.

Examples

Requirement is an abstract class of method components. Examples of the different types of requirements are located with the associated method components:

• Functional Requirements
• Data Requirements
• Quality Requirements
• Interface Requirements
• Constraints