What are Requirements?
"The hardest single part of building a system is deciding what to build... No other part of the work so cripples the
resulting system if done wrong. No other part is more difficult to rectify later."
-- Fred Brooks
Product Engineering
System analysis(World view)
The completeproduct
capabilities
Componentengineering
(Domain view)
Processing requirement
Analysis & DesignModeling
(Element view)
Construction&
Integration(Detailed view)
software
function
SoftwareEngineering
programcomponent
hardware
data behavior
Definitions
Software Requirements Descriptions of the services and constraints of a software system Tells what to build, not how to build it.
Why Spend a Lot of Time?Requirements are the source for all future steps in the software life cycle
Lays the basis for a mutual understanding• Consumer (what they get)• Software producer (what they build)
Identifies fundamental assumptions Potential basis for future contracts
Better get it right - upon delivery, some software is rejected by customers
Changes are cheap - better make them now rather than later
Types of Requirements
Functional vs. Non-functional vs. Domain Reqs Focuses on the visible and invisible features of the software
system and the constraints intrinsic to its application space
User vs. System Requirements Focuses on the User or the System perspective
Functional Non-functional
User Most user reqs are specified as functional
End users do not typically specify; come out of analysis
System System-level standards, such as standard GUI
Many such reqs may be specified here
Functional requirements
Describe functionality or system services Depend on the type of software, expected users and the type of
system where the software is used Functional user requirements are high-level statements of what
the system should do but functional system requirements should describe the system services in detail
Examples “The user shall be able to search either all of the initial set of
databases or select a subset from it.”
“The system shall provide appropriate viewers for the user to read documents in the document store. “
“Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.”
Non-functional requirements
Define system properties and constraints e.g. reliability, response time and storage requirements Constraints are I/O device capability, system representations, etc.
Process requirements may also be specified mandating a particular CASE system, programming language or development method
Non-functional requirements may be more critical than functional requirements. If not met, the system is useless
Non-functional classifications
Product requirements Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc. Example: “4.C.8 It shall be possible for all necessary communication between
the APSE and the user to be expressed in the standard Ada character set”
Organisational requirements Requirements which are a consequence of organisational policies and
procedures e.g. process standards used, implementation requirements, etc. Example: “9.3.2 The system development process and deliverable documents
shall conform to the process and deliverables defined in XYZCo-SP-STAN-95”
External requirements Requirements which arise from factors which are external to the system and
its development process e.g. interoperability requirements, legislative requirements, etc.
Example: “7.6.5 The system shall not disclose any personal information about customers apart from btheir name and reference number to the operators of the system”
Non-functional requirement types
User vs. System Requirements
User requirements Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for customers
Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge
User requirements are defined using natural language, tables and diagrams
System requirements A structured document setting out detailed descriptions of the
system services. A contract between client and contractor More detailed specifications of user requirements Serve as an initial basis for designing the system
Domain requirements
Derived from the application domain and describe system characteristics and features that reflect the domain May be new functional requirements, constraints on existing
requirements, or define specific computations If domain reqs are not satisfied, the system may be unworkable
Typically elicited from domain experts (doctors, lawyers, etc.) or domain-specific standards documents (procedures).
Problems Understandability
• Requirements are expressed in the language of the application domain• This is often not understood by software engineers developing the system
Implicitness• Domain specialists understand the area so well that they do not think of
making the domain requirements explicit
Examples: “Patient information modules must conform to the HL-7 data standards” “The eLearning delivery platform must be ADA-508 compliant”
Requirements Examples
Specify whether the following are Functional, Nonfunctional, and/or Domain
• If nonfunctional, are they Product, Organizational, or External? System or User
1. “The user shall be able to toggle between displaying and hiding all HTML markup tags In the document being edited with the activation of a specific triggering mechanism.”2. “The online credit-card payment facility shall support a minimum of 1000 credit-card transactions per hour”.3. “The doctor shall be able to search the patient tracking system for similar symptoms By typing keywords into a dialog box on the application’s main web page.”
4. “The XML-based content management system shall support UTF-8 encoding”5. “The system shall be up and running 99.9999% of the time”.6. “The system shall support the EDI standard for medical patient data exchange”7. “The user shall save files by selecting the’FileSave’ menu choice”
Other Requirements Classifications
• Change is a Risk! The priority of requirements from different viewpoints changes during
the development process System customers may specify requirements from a business
perspective that conflict with end-user requirements The business and technical environment of the system changes
during its development
• Enduring requirements Stable requirements derived from the core activity of the customer
organisation. e.g. a hospital will always have doctors, nurses, etc. May be derived from domain models
• Volatile requirements Requirements which change during development or when the system
is in use. e.g. In a hospital, requirements derived from health-care policy
Summary
• Requirements are the representation of what the customer wants not how you will implement it.
• Requirements can be classified several ways: Functional vs. Non-functional User vs. System Domain-specific vs. domain-independent Enduring vs. Volatile
• Requirements can be annotated to help manage change
Dr. Gary’s tip: Annotate your features and requirements!!! For each feature/requirement, note the classification above For each feature/requirement, annotate in as many ways that
are useful to managing the scope of impact when they change
Requirements Checklist Example
Attribute Values Description
1. Verifiable Yes/No Can you (did you) write a test to check for it?
2. Traceable GUID Assign a unique identifier to the feature/req
3. Volatility % 0% = Enduring, 100% = (very) Volatile
4. Behavioral Funct/NF if NF, classify (slide 7-8, WhatAreReqs slides
5. Perspective User/System
6. Domain-specific Yes/No if Yes, describe source
7. Priority High/Med/Low Later you can use “scale of 1 to 10” or biz value
Example:REQ V T Vol. B P D Pri Notes
R1 No BN0 10% F U Y L Stable; but need a test
R2 Yes XYZ1 50% F U N M Worried user may change mind
R3 No 80% NF-Org S N H We don’t understand at all!