Software RequirementsBy Pete Sawyer
Presented by Ehsan Ghaneie
EEL6883 – Software Engineering II
Software Requirements
Software requirements concern the specification of software systems
Software systems are always derived from some business problem
They are always embedded in an operational context
They have interfaces to human users, business process elements, or other hardware/software systems
Software Requirements
Derivation of software requirements can rarely be isolated from underlying business problem
Software requirements are not a discrete area of software engineering
They are part of the system engineering process known as requirements engineering
Why is it important?
An effective RE process that minimizes occurrences of requirement errors is critical to success of any development project
The cost of rectifying errors in the requirements increases significantly as development proceeds
Requirements and Constraints
A Requirement defines a property or capability that the system must exhibit in order for it to solve the business problem for which it was conceived Functional Requirements describe a function that the
system must perform Nonfunctional (Extra-Functional) Requirements describe
the qualities of a system How well the system operates within its environment The quality of delivery of functional requirements
Some requirements are emergent properties and dependant on a wide range of factors some of which are hard to analyze and control
Satisfying such requirements depends upon how the whole system operates within its environment, and not just a particular system component
Requirements and Constraints
Requirements are specified at several points on a spectrum that ranges from those with a business focus to those with a technical focus
At the highest level are the goals of a system that set out in very broad strategic terms what is needed to solve some business problem Identifying these needs usually motivates a
development project
Requirements and Constraints
The next level of requirements define what must be observable in a black-box system that solves the business problem These are called user requirements
Stakeholder requirements System requirements
The technically focused requirements exist only to make it possible to satisfy the business focused ones
Constraints are like negative requirements and act to limit the set of possible solutions
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Engineering Process
Is a process that must transform a business problem into a specification of the properties of a system that will provide an appropriate solution to the problem, through a set of activities
What are the activities?
The properties that the system must exhibit must be elicited
Elicited requirements must be subjected to analysis to establish a set of requirements that are correct, complete, and feasible
This set of requirements must be then recorded in a specification document that communicate the requirements to the people who will use them to develop the software
Requirements Engineering Process
The documented requirements must be then validated to ensure the software they specify will meet the needs of the people whom from the requirements were elicited
As development proceeds requirements need to be managed so that changed are controlled
Requirements Engineering Process
This process begins with scoping the system which involves understanding the underlying problem that the system is to address, identifying the goals of the system, and outlining how it will operate in its environment
Then the system requirements are elicited from their sources, analyzed, and validated
For each software component, further analysis of the allocated requirements is used to derive the requirements that fully specify the software
Requirements Engineering Process
It is not always possible to capture all the requirements
If the product’s environment is volatile, the requirements will also be volatile When software products are developed to
compete in the market, the requirements are likely to evolve with the market
Other factors such as meeting the release dates can also affect the RE process
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Elicitation
Requirements elicitation is the process of discovering the requirements
The requirements engineer must identify the sources of requirements, collect information about the problem from these sources, and synthesize requirements from this information
Requirements Elicitation
Requirements elicitation is not a passive learning process about what stakeholders want
Instead, the requirements engineer must dig beneath the stakeholders’ accounts for their concerns, needs, and desires to uncover the underlying business problem
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Sources
First step is to identify stakeholders Large systems have many stakeholders and they are
usually the main sources of requirements Stakeholders must be classified to ensure no
significant sources of requirements are overlooked Role of each stakeholder must be understood and a
representative must be selected to work with the requirement engineer
Since these people are usually busy people, it is important to find people who are motivated to act as “product champions”.
Requirements Sources
Stakeholders have viewpoints These are partial views of the problem
domain which are colored by the stakeholders’ own role and experience
This means requirements might be inconsistent The requirements engineer must recognize
the scope and limitations of stakeholders’ viewpoints to help resolve inconsistencies and apply priorities
Requirements Sources
Stakeholders are not the only sources of requirements
Requirements and constraints might come from the application domain or from business rules that exists in the organizational environment
Key requirements therefore might be hidden in documents, interface specifications, and the experience of domain experts
Requirements Sources
It is important to identify the key requirements that are derived from the application domain and therefore domain expertise plays a crucial role in successful requirements elicitation
Although stakeholders might be good domain experts, but they’re not good candidates mostly because of their view points and often they find it difficult to articulate the tacit knowledge that underpins how the domain operates
If the requirement engineer doesn’t have sufficient domain expertise and can not be trained within a reasonable time, domain experts might have to be brought in from elsewhere to play an active role in the RE process
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Elicitation Techniques
Once sources are identified, the process of collecting knowledge about the problem begins
This starts with understanding the stakeholders’ role in the problem domain, or basically understanding their jobs
The requirements engineer must find an effective way to get the stakeholders analyze what they need
Elicitation Techniques
Users’ scenarios provide a valuable tool for socio-technical systems
The requirements engineer asks the users to identify their main tasks, each consisting of a sequence of events, noting preconditions, post conditions, communication with colleagues, and other events that are involved in the task
Elicitation Techniques
Elicitation may proceed as a series of interviews with individual stakeholders
It is helpful to get them all together (Elicitation workshops) especially once the problem is understood. This helps resolving inconsistencies
But elicitation workshops are not always the best solution as some people may be unwilling or unable to participate or may find scenarios awkward
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Analysis
Requirements Analysis is about understanding the problem and synthesizing a set of requirements that specify the best solution
Analysis is needed to help deepen the understanding of the problem and what is required, and to detect and resolve problems such as inconsistencies and incompatibility with the requirements
Elicitation and analysis are closely coupled
Requirements Analysis
Requirements Analysis will result in a baseline set of requirements, meaning requirements that the system will implant
These are not necessarily everything the stakeholders asked for.
The requirements in the baseline should be necessary and sufficient
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
The System Boundary
Systems are developed to address some strategic goal or goals and these goals are first things that need to be identified
The scope of the project must be defined once the goals are identified
The scope must include a definition of the system boundaries meaning identifying what elements of the problem are going to be addressed by the proposed system
The System Boundary
Outside the system boundaries are the things in the system’s environment hat may impose requirements or constraints
Within the system boundary are all the aspects of the problem for which the proposed system will provide a solution
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Modeling
Engineers use models to help make sense of complex information and visualize complex system properties
Requirements engineers construct models of the problem so they can discover suitable solution requirements
Models are also used to help describe the proposed system to help communicate with the developers
If the dynamic behavior of system can not be analyzed using static models, simulation can be used instead
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Why derive more requirements?
The cost and technical implications of system requirements are often unclear and this makes them hard to assess and validate
The requirements elicited from the stakeholders will typically be expressed in terms of the application domain. The requirements needed by software developers are technical
The requirements need to be translated from domain-centric to software-centric, from abstract to technical
So it is usually helpful to elaborate the system requirements by deriving new requirements that focus on more detailed properties of the proposed system One of the motives for deriving more detailed requirements
is understanding the system implications The other one is to provide enough details for the
developers
Derived requirements
The derivation of requirements is not confined to functional requirements
High-level expressions of non functional requirements need to be quantified and transformed into a set of equivalent functional requirements
The requirements engineer must choose a suitable metric and specify how the system must score against this metric
Derived requirements
The derivation process should stop when the requirements are sufficiently specific for the requirements engineer to be confident that
the requirements are fully understood the developers to commence solution design
Getting too detailed leads to premature design and constraining the design unnecessarily
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Attributes
It is insufficient merely to record the statements of need that express the requirements
Requirements have a number of attributes that should be assigned values in order to ease their management
Some of these attributes are: Identifier, source, date, rationale, type, priority,
stability, verification procedure, and status
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirement Trade-offs
Requirements from different stakeholders are valid but mutually inconsistent
Insufficient resources available to satisfy all the requirements
Stakeholders must be made aware of such conflicts and be explicitly involved in making the trade offs
Agreeing on requirements’ priorities helps the trade-off process
Achieving agreement is often easier if stakeholders are aware of each others’ concern
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Software Requirements Specification
Projects may use up to three kinds of “specification” document at different stages of the RE process
Concept of Operations (ConOps) document sets out the projects vision and scope
System requirements specification defines the requirements for the whole system
Software requirements specification (SRS) specifies the requirements for a software component or subsystem
Software Requirements Specification
Each document has a different purpose System requirements specification must be
readable by the stakeholders to enable them to validate the requirements and approve them as the basis for subsequent development
The SRS, by contrast, is primarily a technical document aimed at the developers. It must specify the software completely and unambiguously
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Validation
Requirements validation can be crudely characterized as ensuring correctness of the requirements
The set of requirements specified in the requirements specification must accurately reflect what is needed to solve the underlying business problem
This concerns not just the correctness of individual requirements, but the correctness, completeness, and consistency of the specification as a whole
The requirements must also conform to appropriate standards, guidelines, and conventions in order to ensure the readability, maintainability, consistency, and other important qualities of a specification document
Requirements Validation
In most cases, the requirements are validated statically
In some cases in which complex dynamic behavior is specified, the requirements may need to be validated dynamically using prototypes or simulations
This kind of validation is costly and it should be done well before the issue of the draft requirements specification document
Requirements Validation
Requirements reviews are a mechanism for validating requirements
Review panel must include both developer and stakeholder representatives
This task can be made easier by including checklists of things to look for
Requirements Validation
Another way to validate the requirements is to write test cases against the requirements
If it proves excessively hard to plan how a requirement can be verified then there is something wrong with the requirement
Although non functional requirements are inherently hard to verify, they must be verifiable if they are to serve any useful purpose
Requirements Validation
Once the requirements specification document has been validated and any necessary changed have been made, the requirements specification document will be “signed off” on
Although a formal “signing off” may not occur, it will considerably complicates the requirements management tasks
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirement Management
Includes: Change control Version control Requirements tracing Status tracking
A fundamental prerequisite for each of these is that requirements must be uniquely identifiable
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Change Control
Changes will always occur after the requirements specification document has been signed off on
It is crucial that change is not permitted to occur without control
Uncontrolled or ad-hoc changes to the requirements will make project planning impossible resulting in a system that is late and/or over budget
Change Control
A change request has to go through a formal process and cost/benefit analysis has to be performed before a decision is made to accept or reject or perhaps postpone it to a later release
The implications of NOT approving the change must also be considered
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Version Control
Requirements changes must be recorded This includes the details of the change, the date of
approval, and the rational for the change, including the rationale for the decision to approve the change
Changes then need to be communicated to the developers and this requires issuing of new versions of the requirements specification document
A numbering system for document versions is essential
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Requirements Tracing
Requirements must be traced in order to enable change control, and status tracking
At a minimum, requirements tracing means recording the derivation relationships between requirements
Requirements Tracing
Tracing should be possible both forward and backward Forward tracing is necessary to assess the
impact of requirements down through its derived requirements and into the components in which they are allocated
Backward tracing is required so it is possible to ensure that the system will ultimately solve the business problem adequately if one of the derived requirements is changed for any reason
Software Requirements Requirements Engineering Process
Requirements Elicitation Requirements Sources Elicitation Techniques
Requirements Analysis The System Boundary Requirements Modeling Derived Requirements Requirements Attributes Requirement Trade-offs
Software Requirements Specification Requirements Validation Requirements Management
Change Control Version Control Requirements Tracing Status Tracking
Status Tracking
Requirements can be classified according to weather they are pending, approved, rejected, deferred, validated, completed, or cancelled
Managing a record of requirements’ status is important for tracking the project progress
Questions?