requirement engineering

1. Chapter 3
Introduction to Requirement Engineering
Shwaga A.

2. 2
 What are requirements?
 Types of requirements
 Functional, non-functional & domain requirements
 Business, user & System requirements
 Requirement Engineering: Introduction
 What is requirement engineering?
 Why Requirement Engineering?
 Requirement requirements: How- Requirement
Engineering Activities
 Requirement requirements: When
 Stakeholders in Requirement Engineering: Who
Contents

3. 3
 Software requirements are the descriptions of the system
services (essential & desired) and constraints (on System
operation and software development process).
 Requirements are statements of what the system must do,
how it must behave in particular situations, the properties it
must exhibit, the qualities it must possess, and the
constraints that the system and its development must satisfy.
 According to Institute of Electrical and Electronics Engineers
(IEEE) standard 729, a requirement is defined as follows:
 a condition or capability needed by a user to solve a
problem or achieve an objective
What are requirements?

4. 4
Requirements might describe:
•A user-level facility (e.g. the word processor must include a
spell checking and correction command)
•A very general system property (e.g. the system must ensure
that personal information is never made available without
authorization)
•How to carry out some computation (e.g. the overall mark is
computed by adding the students exams, project & individual
assignment marks based on the following formula. Total =
[mid exam + final exam + project + individual assignment])
• constraint on the development of the system (e.g.
• The system must be developed using java,
• The system will only use the data contained in the
existing corporate database.) Etc..

5. 5
 As much as possible, requirements should describe what the
system should do, but not how it should do it.
 However, sometimes it is necessary for the requirement
documents to include information about the design of the
system. Because:
 Readers are often practical engineers – they can relate it to
implementation descriptions.
 The system may be one of several systems in an environment
- to be compatible with its environment specifying
implementation issues are important.
 The specifiers are often experts in the application domain
where the system is to be used. The requirements may be
descriptions of how to carry out a computation using
application domain. E.g. accounting equation.
What are requirements?...

6.  The most common reasons for project failures are not technical.
Below the main reasons why projects fail is identified. The data
is drawn from surveys conducted by the Standish Group in 1995
and 1996.
• Incomplete requirements 13.1%
• Lack of user involvement 12.4%
• Lack of resources 10.6%
• Unrealistic expectations 9.9%
• Lack of executive support 9.3%
• Changing requirements/specifications 8.7%
• Lack of planning 8.1%
• Didn’t need it any longer 7.5%
Hence giving emphasis to requirements is crucial in any system dev’t.
6

7. 7
 Software requirements are often classified as functional
requirements, non-functional requirements or domain
requirements.
 Functional requirements: Functional requirements capture
the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is
required to perform. i.e. “What the system should do?”.
 IEEE defines functional requirements as 'a function that a
system or component must be able to perform.'
 Statements of services the system should provide, how the
system should react to particular inputs and how the
system should behave in particular situations.
Types of requirements

8.  In order to find out functional requirements of a system try to
answer the questions below
 What inputs the system should accept?
 What outputs the system should produce?
 What data the system should store that other systems might use?
 What computations the system should perform?
 E.g. The system shall display the longitude and latitude of the
student through GPS.
 Non-functional requirements (NFRs): define the overall qualities or
attributes of the resulting system like: portability, (security),
maintainability, reliability, scalability, performance, reusability,
flexibility,…
 They are basically the quality constraints that the system must
satisfy according to the project contract.
8

9. 9
 Non-functional requirements can be
 Product requirements: Requirements which specify that the
delivered product must behave in a particular way e.g.
execution speed, reliability, etc.
 Example: The system shall not fail more than two times per week.
 Process requirements: are constraints placed upon the development
process of the system
 Example: The system must be developed using Java.
 External requirements: Requirements which arise from factors
which are external to the system and its development process .
 Example: The system shall not disclose any personal information
about customers apart from their name and reference number to
the operators of the system.
Non-Functional Requirements…

10. 10
Non-Functional Requirements…
Non-functional
requirements
Process
requirements
Product requirements External
requirements
Delivery
requirements
implementation
requirements
standards
requirements
Usability requirements
Reliability requirements
Safety requirements
Efficiency requirements
Performance requirements
Capacity requirements
Legal
constraints
Economic
constraints
Interoperability
requirements

11. 11
 Functional Vs Non-Functional Requirements
 There is no a clear distinction between functional and non-
functional requirements.
 Whether or not a requirement is expressed as a functional
or a non-functional requirement may depend on:
 the level of detail to be included in the requirements
document.
 the degree of trust which exists between a system
customer and a system developer.
Types of requirements…

12. 12
 Example: The system shall ensure that data is protected from
unauthorised access.
 Conventionally, this would be considered as a non-functional
requirement because it does not specify specific system
functionality which must be provided. However, it could
have been specified in slightly more detail as follows:
 The system shall include a user authorisation procedure
where users must identify themselves using username and
password. Only users who are authorised in this way may
access the system data.
 In this form, the requirement looks rather more like a
functional requirement as it specifies a function (user login)
which must be incorporated in the system.
Types of requirements…

13. 13
 Domain Requirements
 Domain requirements are expectations related to a particular type of
software, purpose or industry vertical like military, medical and
financial industry sectors
 Requirements that come from the application domain of the system
and that reflect characteristics of that domain.
 They are the requirements which are characteristic of a particular
category or domain of projects.
 Domain requirements are not from specific needs of system users
and can be functional or non-functional.
 They usually include specialized terminologies reference to domain
concept - they are difficult to understand
 They may be new functional requirements (may be defining specific
computations) or can be constraints on existing requirements.
 If domain requirements are not satisfied, the system may be
unworkable.
Types of requirements…

14.  For example,
 The software must be developed in accordance with IEC 60601
regarding the basic safety and performance for medical electrical
equipment.
Domain requirements problems
 Understandability
 Req’ts are expressed in the language of the application
domain; often not understood by software engineers.
 Implicitness
 Domain specialists understand the area so well that they
do not think of making the domain requirements explicit.
14

15. 15
 Kinds of requirements based on the intended purpose
and target audience:
 Business Requirements:
 Describes why the project is being started and what is its
scope and objective.
 These are used to state the high-level business objective of
the organization or customer requesting the system or
product.
 They are used to document main system features and
functionalities without going into their nitty-gritty (basic
important) details.
 E.g. Implement a web and mobile-based employee tracking
system that tracks field employees and increases efficiency by
means of monitoring employee activity, absenteeism, and
productivity.

16. 16
 User Requirements:
 User requirements add further detail to the business
requirements.
 What services the system is expected to provide to system
users and the constraints under which it must operate.
 They are called user requirements because they are
written from a user’s perspective and the focus of user
requirement describe tasks the user must be able to
accomplish in order to fulfill the above stated business
requirements.
 E.g. The system should be easy to use by site engineers
and should be organized in such a way that user errors
are minimized.

17. 17
System Requirements:
 Detailed description of what the system should do
including the software system's functions, services, and
operational constraints.
 The system requirements document (sometimes called a
functional specification) should define exactly what is to
be implemented.
 are expanded versions of the user requirements that
are used by software engineers as the starting point
for the system design.
 They add detail and explain how the user requirements
should be provided by the system.
 Written as a contract between client and contractor

18. 18

19. 19
Requirement Engineering: Introduction
 Requirement Engineering is the process of defining,
documenting and maintaining the requirements.
 It is the process of understanding and defining what services
are required and identifying the constraints on these services.
 Requirement engineering provides
 the appropriate mechanism to understand what the customer desires,
 analyzing the need, and assessing feasibility,
 negotiating a reasonable solution,
 specifying the solution clearly,
 validating the specifications and
 managing the requirements as they are transformed into a working
system.

20.  Requirements engineering is complex because of
the three roles involved in producing even a single
requirement:
 the requestor (referred to as the "user" in the IEEE
definition),
 the author (who will document the requirements).
 the developer (who will design and implement the
system), and
20

21. Contd…
 Typically, the requestor understands the problem to be
solved by the system but not how to develop a system.
 The author needs to create a statement that
communicates unambiguously to the developer what the
requestor desires. Hence, requirements address a
fundamental communications problem.
 The developer understands the tools and techniques
required to construct and maintain a system but not the
problem to be solved by that system.
21

22. 22
 There are many issues that can have a negative impact on software
development projects and products if practitioners don’t do a good
job of defining their software requirements.
 These issues include:
 Incomplete requirements
 software product does not meet all of the customer and user’s
needs.
 Lack of user involvement
 Requirements churn
 changes in the requirements after they are initially agreed to
and baselined.
 Wasted resources
 Requirements errors account for 70 to 85 percent of the
rework costs on a software project
Why Requirement Engineering?

23.  The cost to fix a software defect varies according to how far along
you are in the cycle, according to authors Roger S. Pressman and
Robert B. Grady.
23
Why Requirement Engineering?
Variations in costs to fix a software defect

24. 24
 Gold plating
 developer adds functionality to the software that was not in the
requirements.
 Inaccurate estimates
 Without a clear picture of that scope, estimates of the project
schedule, cost, and quality will be less accurate.
Why Requirement Engineering?...
The hardest single part of building a software system is deciding
precisely what to build. No other part of the conceptual work is as
difficult as establishing the detailed technical requirements, including
all the interfaces to people, to machines, and to other software systems
No part systems of the work so cripples the resulting system if done
wrong. No other part is more difficult to rectify later. (Brooks, 1987)
No Silver Bullet: Essence and Accidents of Software Engineering.

25. 25
 Stakeholders are individuals who affect or are affected
by the software product and therefore have some level of
influence over the requirements for that software product.
 In order to develop a good requirement document, it is
imperative to involve all kinds of user in the requirement
engineering process.
 You need to identify the stakeholders in a system and
discover their requirements.
 If you don’t do, you may find that they insist on changes
during the system development or after it has been
delivered for use.
Stakeholders: The Who of RE

26. 26
 There are three main categories of stakeholders:
 the acquirers of the software product
 the suppliers of the software product and
 other stakeholders: legal or contract management, sales
and marketing, upper management,…
 The acquirer type stakeholders can be
 customers who request, purchase, and/or pay for the
software product
 users, also called end-users, who actually use the product
directly
 The suppliers of the software product include individuals and
teams that are part of the organization that develops, distribute,
delivery methods (for example, outsourcing).
Stakeholders…

27. 27
 Software requirements engineering is made up of two major
processes: requirements development and requirements
management.
 Requirements development encompasses all of the activities
involved in eliciting, analyzing, specifying, and validating the
requirements.
 It occur during the early concept and requirements phases of the life
cycle.
 Requirements management is the process of understanding and
controlling changes to system requirements and maintaining links
between dependent requirements.
 The activities used for requirement engineering vary widely
depending on the application domain, the people involved and the
organisation developing the requirements.
How Requirement Engineering ? Activities

28. 28
 However, there are a number of generic activities common to all
processes: Feasibility studies, Requirements elicitation and analysis,
Requirement specification, Requirements validation, Requirements change
management
Requirement Engineering Activities…

29. 29
 A feasibility study decides whether or not the proposed system is
worthwhile.
 A short focused study that checks if the system;
 contributes to organisational objectives?
 can be engineered using current technology and within budget?
 can be integrated with other systems that are used?
 Unless the answers for the above questions are affirmative it has
no real value to the business.
Feasibility study

30. 30
 Involves finding out the services that the system should provide
and the system’s operational constraints.
 Is the most difficult, most critical, most error-prone, and most
communication-intensive aspect of software development.
 Why Requirements elicitation and analysis is a difficult process?
 Stakeholders often don’t really know what they want from the computer
system.
 Stakeholders naturally express requirements in their own terms.
 Different stakeholders have different requirements.
 Political factors may influence the requirements of the system.
 The requirements change during the analysis process.
 New stakeholders may emerge and the business environment change.
Requirements elicitation & Analysis...

31.  The objectives of requirement analysis & negotiation is to
establish an agreed set of requirements which are complete and
consistent.
 During analysis process
 Missing requirements
 Requirements conflict
 Ambiguous requirements are discovered
 Overlapping requirements
 Unrealistic requirements
 For conflicting & ambiguous requirements stakeholders should
negotiate and agree on modifications and simplifications of the
requirements
Requirements Analysis & Negotiation
31

32. Elicitation techniques
 Traditional techniques
 Introspection
 Reading existing documents
 Interviews
 Open-ended
 Structured
 Surveys / Questionnaires
 Collaborative techniques
 Group techniques
 Focus Groups
 Brainstorming
 JAD/RAD workshops
 Prototyping
 Cognitive techniques
 Task analysis
 Card Sorting
 Contextual approaches
 Participant Observation
32

33. Introspection
 Is the mental thoughts of the requirements engineering about
the wants and needs of the stakeholders about the systems.
 It amounts to imagining what kind of system I would want if
I were doing this job, using this equipment, etc.
 There are almost no costs of this technique.
 The analyst should be expert in the business processes of the
users
33

34.  Sources of information:
 Company reports, organization charts, policy manuals, job
descriptions, reports, documentation of existing systems, etc.
 Helps to prepare for other types of fact finding.
 Written documents often do not match up to reality.
Background Reading
34

35.  Probably the most common technique of requirements
elicitation.
 Interviewers must be open-minded and should not approach the
interview with pre-conceived notions about what is required.
 Stakeholders must be given a starting point for discussion (a
question, a requirements proposal, an existing system)
 Structured (closed) interviews
 Stakeholders answer a predefined set of questions.
 Non-structured (open) interviews
 No predefined agenda
 In practice: mixed interview types are normal
Interview
35

36.  The surveys are used to conduct the RE over a large population of
interest. This technique covers the whole geographical region to get
the large set of requirements.
 Can quickly collect info from large numbers of peoples
 Success depends on the return rate
 No room for users to convey their real needs
Surveys and Questionnaires
36

37. Collaborative techniques: Group techniques
 Brainstorming
 It refers to the process of systematic and liberal generation of a
large volume of ideas from a number of participants in a need to
solve a problem.
 So much severe criticism is not allowed in this type of technique
because due to this the biasness can be generated.
37

38. Prototyping
 A prototype is an initial version of a system which may be
used for experimentation.
 Prototypes are valuable for requirements elicitation
because users can experiment with the system and point
out its strengths and weaknesses of the implemented
requirements.
38

39. Contextual approaches: Participant Observation
 People often find it hard to describe what they do because it is so
natural to them.
 Actual work processes often differ from formal, prescribed processes.
 Sometimes the best way to understand it is to observe them at
work.
 highly authentic requirements engineering tool
 Mostly the results of observations are wrong as the customer
problems cannot be understand as they are being watched during
observations and adjust themselves.
39

40. 40
 In this activity complete description of the behavior of the
system is developed.
 The requirements specification document states in precise and
explicit language those functions and capabilities a software
system must provide, as well as stating any required constraints
by which the system must abide.
 Recommended approaches for the specification of software
requirements are described by IEEE 830-1998.
Software Requirement Specification

41.  There is no formulaic way to write excellent requirements.
 It is largely a matter of experience and learning from the
requirements problems you have encountered in the past.
 Here are a few guidelines to keep in mind as you document
software requirements.
 Keep sentences and paragraphs short. Use the active voice.
Use proper grammar, spelling, and punctuation.
 To see if a requirement statement is sufficiently well defined,
read it from the developer’s perspective.
 Watch out for multiple requirements that have been
aggregated into a single statement.
Guidelines for Writing Quality Requirements

42.  Write requirements at a consistent level of detail throughout
the document.
 Requirement authors often struggle to find the right level of
granularity. Avoid long narrative paragraphs that contain
multiple requirements.
 Avoid stating requirements redundantly in the SRS.
 Define standard templates for describing requirements
 Use language simply consistently and concisely.
 Use diagrams appropriately
 Supplement natural language with other description of
requirements
 Specify requirements quantitatively
Guidelines for Writing Quality Requirements…

43. 43
 Correct – A requirement has to be correct.
 The information used to create it has to be correct and has to
reflect reality.
 Necessary – A requirement has to be necessary.
 If it wasn’t included, what’s the worst that could happen? If you
and the users are willing to accept those consequences, then it
probably isn’t really necessary.
 Focus(not amalgamated) – A requirement has to focus on one
thing.
 Don’t write one requirement that specifies multiple needs –
instead, break it up into several requirements.
 Don’t– “The meter shall display a minimum of -999 and a
maximum of 999 volts.”
 Do – “The meter shall display a minimum value of -999 volts.”
and “The meter shall display a maximum value of 999 volts.”
Characteristics of requirements

44. 44
 Feasible – A requirement must be feasible/practical.
 If you cannot implement it with the budget, schedule, resources, and
other limitations that are available to your project, then either it must
be dropped or the project has already failed.
 Verifiable – A requirement has to be testable/testable.
 Once a solution for a requirement has been implemented, you need some way
to know if the design and implementation are correct. If you can’t test the
requirement, then the product is indeterminate – you can’t prove that what
you built is right, and you may never get acceptance from the customer
 Requirement: The treadmill shall run continuously for 5,000 hours
at 5 mph without failing.
 Questions to ask: How are we going to test this? Is it possible? Is it
necessary?
 Better: The treadmill shall have a Mean Time Between Failure
(MTBF) of less than X with . . .
More on characteristics of requirements…

45. 45
 Precise - requirement should be evident and unambiguous
 The system shall accept valid employee ID numbers from 1 to
9999.
 Are all numbers between 1 and 9999 valid? Is 2 OK as well
as 0002?
 The system shall accept only valid ID numbers as defined
elsewhere. No other valid number will be accepted unless it is
an integer between 1 and 9999 inclusive, represented without
leading zeros.
 Clear: A requirement has to be clear and unambiguous
 Requirement: The treadmill shall support a maximum load of three.
 Questions to ask: Three what? This is ambiguous and unclear.
 Better: The treadmill shall support a maximum power load of three watts.
More on characteristics of requirements…

46. 46
Requirement Document- IEEE/ANSI 830-1993

47. 47
Requirement Document- IEEE/ANSI 830-1993

48. 48
 Concerned with demonstrating that the requirements define the
system that the customer really wants and they are error free.
 To validate requirements we may use the following requirement
validation techniques:
 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check requirements.
 Test-case generation
 Developing tests for requirements to check testability.
Requirements validation

49. 49
 Requirements management is the process of managing
changing requirements during the requirements engineering
process and system development.
 It includes:
 Requesting changes to the baselined requirements
 performing impact analysis for the requested changes
 approving or disapproving those changes, and
 implementing the approved changes
 ensuring that all work products and project plans are kept
consistent and tracking the status of the requirements as one
progresses through the software development process.
Requirements management