software requirements by pete sawyer presented by ehsan ghaneie eel6883 – software engineering ii

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


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


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


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


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

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

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


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


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


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

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


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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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?

software requirements by pete sawyer presented by ehsan ghaneie eel6883 – software engineering ii

Documents

constraints requirements

focused requirements

level of requirements

negative requirements

requirements engineering

system boundary requirements

system engineering process

business process elements