Requirements Engineering Process

Requirements Engineering Process

Week 3

The outlineRequirements engineering and

requirements managementWhat is requirementsClassification of requirementsRE processStakeholders in RE

The context of RE

• System users and other stakeholders may– not be able to accurately describe what they do– not know what is technically feasible,– change their minds once they see the possibilities

more clearly, and– often not appreciate the complexity inherent in

software engineering, and the impact of changed requirements

System developers require•The requirements must

be feasible, necessary and sufficient

Requirements Engineers System

development domain

Problem domain

Overview This course looks at software requirements from

both engineering and management perspectives.

It is an engineering activity because – identifying appropriate methodologies to develop

software solutions and – identifying cost effective ways of doing so.

In other words, the aim of RE is to introduce engineering principles into the practice of software systems analysis while integrating RE with a quality assurance process of utmost value to practitioners.

OverviewRE is the systematic process of developing

requirements through an iterative co-operative process of analyzing the problem, documenting the resulting observations in a variety of representation formats and checking the accuracy of the understanding gained (Pohl, 1993)– A social process– A variety of representation formats– Understanding and validating the requirements

Typical RE products– System requirements specification, and associated

analysis models of requirements baseline– A vision and scope document– A requirements specification

Overview Requirements change during the software

development lifecycle and evolve after the system has become operational.

Thus, RE is also a “management” activity as it is concerned with managing RE activities such as– monitoring product requirements and– managing the project scope, cost and schedule

throughout the software development process, while ensuring that all essential business

applications are delivered as specified in different requirements documents on different levels, for example, product and project levels.

OverviewRM involves processes, tools and practice to

maintainthe integrity and accuracy of the requirementsagreement– Change control –managing changes to agreed

requirements– Version control –identifying document versions

and requirements revisions– Requirements tracing –managing relationships

between requirements, and dependencies among requirement document

– Requirements status tracking –defining and tracking status

Marketing, Customers, Management Requirements

Analyze,Document,Review,Negotiate

Baselined Requirements

currentbaseline

revisedbaseline

requirementschangeProcess

Marketing,customers,management

Requirementschanges

Projectchanges

ProjectEnvironment



What is requirements A requirement is

– a singular documented need of what a particular product or service should be or do. - Wikipedia

Requirements are – specifications of the services that the system should

provide, the constraints on the system and the background information that is necessary to developing the system (Zave 1997)

Requirements are … – a specification of what should be implemented. They

are descriptions of how the system should behave, or of a system property or attribute.

They may be – a constraint on the development process of the

system (Sommerville and Sawyer 1997)

R2: The alarm signal shallstart immediately after thedetection of the openWindow or door. (refer toR78)– R2.1: The alarm signal shallbe deactivated by thepolice, by the owner, orAutomatically after 20 min.– … …– R78: The time periodbetween motion detectionand start of alarm signalshall be less than 0.5seconds

Home security requirements for a Home Automation System(HAS)

Example

Levels of requirements Business requirements

– High-level objectives of organization or customer requesting the system

– Vision and scope document User requirements

– Statements of the services and the operational constraints– E.g. use case or scenario descriptions

System requirements– Detailed descriptions of the system services– E.g. development, testing, quality assurance, project

management (schedule, budget, etc.) Software specification

- A detailed software description which can serve as a basis for a design

or implementation

Examples: home security requirements in HAS

Business Requirements: The HAS shall ensure home security.

User Requirements: The HAS shall protect again burglary.

System Requirements– F1: Video surveillance; F2: Alarm activation; … … ;– Fn: Alarm call

Software Specification– R2: The alarm signal shall start immediately after the

detection of the open window or door.– R2.1: The alarm signal shall be deactivated by the

police, by the owner, or automatically after 20 min.– R79: The time period between motion detection and

start of recording shall be less than 0.5 seconds.



Requirements classificationRequirements may be functional or non-

functional– Functional requirements (FRs) describe the

functionality of the system, can be modeled with use cases

– Non-functional requirements (NFRs) describe system properties related to e.g. system performance, usability, security, maintainability…

– Constraints impose limitations on the design of the system , or process by which it is developed, that do not affect the external behavior

– E.g. CASE system, programming language or development method

NFR-types Product requirements

– Requirements which specify that the delivered product must behave in a particular way

– E.g. R78: The time period between motion detection and start of alarm signal shall be less than 0.5 seconds.

• Organizational requirements– Requirements which are a consequence of organizational

policies and procedures – E.g. The signal powerline transmission shall use the standard

X10.

• External requirements– Requirements which arise from factors which are external to the

system and its development process– E.g. The alarm signal shall be deactivated by the police, by the

owner, or automatically after 20 min

NFR measures – turn vague idea about quality into measurable

Speed Process transaction/secondUser/Event response timeScreen refresh time

Size M BytesNumber of ROM chips

Ease of use Training timeNumber of help frames

Reliability Mean time to failurePercentage of events causing failure

Robustness Probability of data corruption on failure

AvailabilityTime to restart after failureRate of failure occurrenceProbability of unavailability

Portability Percentage of target dependent statementsNumber of target systems



RE process – inputs and outputs

RE process

Agreed requirement

s

System specification

System models

Existing system

information

Stakeholder needs

Organisational standards

Regulations

Domain information

Input/output descriptionInput or output Type Description

Existing systeminformation

Input Information about the functionality of systems to be replaced orother systems which interact with the system being specified

Stakeholder needs Input Descriptions of what system stakeholders need from the system tosupport their work

Organisationalstandards

Input Standards used in an organisation regarding system developmentpractice, quality management, etc.

Regulations Input External regulations such as health and safety regulations whichapply to the system.

Domain information Input General information about the application domain of the systemAgreed requirements Output A description of the system requirements which is understandable

by stakeholders and which has been agreed by themSystemspecification

Output This is a more detailed specification of the system functionalitywhich may be produced in some cases

System models Output A set of models such as a data-flow model. an object model, aprocess model, etc. which describes the system from differentperspectives

Examples - HAS Existing system information– “The power outlets shall be shut down on the detection of fire.”

Stakeholder needs– “The resident shall be informed immediately after the detection of an open

window or door”

Organizational standards– “The signal powerline transmission shall use the standard X10”

Regulations– “The method for temperature control in individual living or work rooms shall

be EP0631219 (December, 1994).”

Domain information– “The password shall consist of at least 10 characters and include special

characters (such as numbers). The password shall be changes every 3 months, and an old password can not be used again”

Spiral model of the RE process

Requirements elicitation Requirements analysis andnegotiation

Requirements documentationRequirements validation

Informal statement ofrequirements

Agreedrequirements

Draft requirementsdocument

Requirementsdocument and

validationreport

Decision point:Accept documentor re-enter spiral

START

RE process activitiesRequirements elicitation– Requirements discovered through consultation

with stakeholders, from system documents, domain knowledge and market studies

Requirements analysis and negotiation– Requirements are analyzed and conflicts

resolved through negotiationRequirements documentation

- A requirements document is producedRequirements validation– The requirements document is checked for

consistency and completeness

RE variabilityRE processes vary radically from one

organization to anotherFactors contributing to this variability

include– Technical maturity– Disciplinary involvement– Organizational culture– Application domain

There is no ‘ideal’ requirements engineering process

Risks from inadequate requirements

processesInsufficient user involvement -> unacceptable

products– Creeping user requirements -> overruns/degrade

product quality– Ambiguous requirements -> ill-spent time and rework– Overlooked user classes -> dissatisfied customers– Minimal specifications -> missing key requirements

Incompletely defined requirements -> impossible to accurate project planning and later tracking– Missing requirements are hard to spot because they

are not there! ( Wiegers, 2003) Gold-plating -> unnecessary features

Key benefits of good requirementsprocesses

Better control of complex projectsImproved system quality and

customer satisfactionReduced project cost and delayImproved team communication

Tools support for RE processSupport for requirements engineering is

limited because of the informality and the variability of the process– Modeling tools support the development of

system models which can be used to specify the system and the checking of these models for completeness and consistency

–Management tools help manage a database of requirements and support the management of changes to these requirements

A requirements management system

Requirementsdatabase

NLrequirements

documentReq. convertor

WP linker

Traceabilitysupport system

Report generator

Traceabilityreport

Requirementsreport

Req. browser Req. querysystem

Change controlsystem

Requirements management tools Requirements browser Requirements query system Traceability support system Report generator Requirements converter and word

processor linker Change control system

Requirements management toolsList of requirements toolsINCOSE requirements management tool

survey:– http://www.paper-review.com/tools/rms/read.php– http://easyweb.easynet.co.uk/~iany/other/

vendors.htm– http://www.volere.co.uk/tools.htm

A requirements tool for agile web application

Development– http://demo.agiletool.org/



Stakeholders in the RE process

Stakeholders include the parties that can influence or be affected by a certain problem

Stakeholders - RolesRE involves stakeholders– Interested in the problem to be solved

(end-users)– Interested in the solution (system

designer)

Type of stakeholders

Role descriptions

Role DescriptionDomain expert Responsible for providing information about the

application domain and the specific problem in thatdomain which is to be solved.

System end-user Responsible for using the system after deliveryRequirements engineer Responsible for eliciting and specifying the system

requirementsSoftware engineer Responsible for developing the prototype software

systemProject manager Responsible for planning and estimating the

prototyping project

Stakeholder analysis

Stakeholder analysisStakeholder analysis is an approach for

understanding a system by identifying the stakeholders in the system,

and assessing their respective interests in, or influence on the system– Stakeholder identification– Stakeholder profiling– Stakeholder prioritization

Stakeholder analysis process

Stakeholder identificationBaseline stakeholders -> the network of

stakeholders(Sharp et al. 1999)– Baseline stakeholders: Users, Developers,

Legislators, Decision makers, Physical environments

– A combination of following methods is useful for exploring the network of stakeholders• Checklist• Self-selection (Documentation studies)• Experts• Identified stakeholders (brainstorming, interview)

http://eprints.ucl.ac.uk/744/1/1.7_stake.pdf

Example of checklist questionsWho are the user groups of the system?– Who is the customer (economic buyer) for the

system?– Who else will be affected by the outputs the

system produces?– Who will evaluate and approve the system

when it is delivered and deployed?– Are there any other internal or external users?– Who will maintain the new system?– Is there anyone else who cares?– What other systems interact with this system?

Stakeholder profilingThe stakeholders profile records their own

concerns of the system, including their interests, characteristics, etc.– Definition, job description, relationship to the

development team– Goals, needs and desires, concerns, declared

interests, responsibilities, tasks to be performed– The relationship between stakeholders,

stakeholder power and importanceMethods useful for profile creation

– Conversational methods –interview, workshop, …– Analytic methods, document studies, …

Stakeholder profile - HASStakeholder Major value Attitudes Major

interestsconstraints

Resident Authorization control of the home appliances, reduce cost

Concern about ease-of-use; most residents excited

Comfort, security and life safety

Control should be largely image-based and self-explanatory

Stakeholder relationship identification and prioritization

Understand the relationships between stakeholders– Identify conflicts of interests between stakeholders– Identify relations between stakeholders that may

enable ”coalitions”of project sponsorship, ownership and cooperation

Assess the importance and influence of each stakeholder on the project– How stakeholders problems, needs, and interest

coincides with the aims of the project– (How powerful the stakeholder is)– (Stakeholder prioritization –Importance/Influence

grid)

Documents

Requirements Engineering Process