Post on 21-Mar-2016
description
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
The outlineRequirements engineering and
requirements managementWhat is requirementsClassification of requirementsRE processStakeholders in RE
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.
The outlineRequirements engineering and
requirements managementWhat is requirementsClassification of requirementsRE processStakeholders in RE
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
The outlineRequirements engineering and
requirements managementWhat is requirementsClassification of requirementsRE processStakeholders in RE
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/
The outlineRequirements engineering and
requirements managementWhat is requirementsClassification of requirementsRE processStakeholders in RE
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)