1. Requirements Engineering Process
Week 3

2. The outline Requirements engineering and requirements management
What is requirements
Classification of requirements
RE process
Stakeholders in RE

3. The context of RE System development domain Problem domain
Requirements Engineers
System
development domain
Problem domain
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

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

5. Overview
RE 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

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

7. Overview RM involves processes, tools and practice to maintain
the integrity and accuracy of the requirements
agreement
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

8. Marketing, Customers, Management
Requirements
Analyze,
Document,
Review,
Negotiate
Baselined Requirements
current
baseline
revised
baseline
Marketing,
customers,
management
requirements
change
Process
Project
Environment
Requirements
changes
Project
changes

9. The outline Requirements engineering and requirements management
What is requirements
Classification of requirements
RE process
Stakeholders in RE

10. What is requirements A requirement is Requirements are
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)

11. Example Home security requirements for a Home Automation System
(HAS)
R2: The alarm signal shall
start immediately after the
detection of the open
Window or door. (refer to
R78)
– R2.1: The alarm signal shall
be deactivated by the
police, by the owner, or
Automatically after 20 min.
– … …
– R78: The time period
between motion detection
and start of alarm signal
shall be less than 0.5
seconds

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

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

14. The outline Requirements engineering and requirements management
What is requirements
Classification of requirements
RE process
Stakeholders in RE

15. Requirements classification
Requirements 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

17. NFR
product
usability
Reliability
Portability
Efficiency
Performance
space
External
Interoperability
Legislative
Privacy
Safety
Ethical
Organizational
Delivery
Standard
Implementation

18. NFR-types Product requirements • Organizational 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

19. NFR measures – turn vague idea about quality into measurable
Speed
Process transaction/second
User/Event response time
Screen refresh time
Size
M Bytes
Number of ROM chips
Ease of use
Training time
Number of help frames
Reliability
Mean time to failure
Percentage of events causing failure
Robustness
Probability of data corruption on failure
Availability
Time to restart after failure
Rate of failure occurrence
Probability of unavailability
Portability
Percentage of target dependent statements
Number of target systems

20. The outline Requirements engineering and requirements management
What is requirements
Classification of requirements
RE process
Stakeholders in RE

21. RE process – inputs and outputs
Existing system information
Agreed requirements
RE process
Stakeholder needs
System specification
Organisational standards
System models
Regulations
Domain information

22. Input/output description

23. 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 EP (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”

24. Spiral model of the RE process

25. RE process activities Requirements 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 negotiation
Requirements documentation
- A requirements document is produced
Requirements validation
The requirements document is checked for consistency and completeness

26. RE variability
RE processes vary radically from one organization to another
Factors contributing to this variability include
Technical maturity
Disciplinary involvement
Organizational culture
Application domain
There is no ‘ideal’ requirements engineering process

27. Risks from inadequate requirements processes
Insufficient 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

28. Key benefits of good requirements processes
Better control of complex projects
Improved system quality and customer satisfaction
Reduced project cost and delay
Improved team communication

29. Tools support for RE process
Support 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

30. A requirements management system

31. Requirements management tools
Requirements browser
Requirements query system
Traceability support system
Report generator
Requirements converter and word processor linker
Change control system

32. Requirements management tools
List of requirements tools
INCOSE requirements management tool survey:
A requirements tool for agile web application
Development

33. The outline Requirements engineering and requirements management
What is requirements
Classification of requirements
RE process
Stakeholders in RE

34. Stakeholders in the RE process
Stakeholders include the parties that can influence or be affected by a certain problem
Stakeholders - Roles
RE involves stakeholders
Interested in the problem to be solved (end-users)
Interested in the solution (system designer)

35. Type of stakeholders

36. Role descriptions

37. Stakeholder analysis

38. Stakeholder analysis
Stakeholder 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

39. Stakeholder analysis process

40. Stakeholder identification
Baseline 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)

41. Example of checklist questions
Who 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?

42. Stakeholder profiling
The 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 importance
Methods useful for profile creation
Conversational methods –interview, workshop, …
Analytic methods, document studies, …

43. Stakeholder profile - HAS
Major value
Attitudes
Major interests
constraints
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

44. 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)