Chapter 4: Requirement Engineering
Chapter 4: Requirement Engineering
Chapter 4: Requirement Engineering
1
Objectives
• Introduce software requirements and to discuss the processes involved
in discovering and documenting these requirements.
• Understand the concepts of user and system requirements
• Understand the differences between functional and nonfunctional
software requirements.
• Understand the principal requirements engineering activities of
elicitation, analysis and validation, and the relationships between these
activities.
• Understand why requirements management is necessary and how it
supports other requirements engineering activities.
2
Topics Covered
User and System Requirements
Functional and non-functional requirements
Requirements Engineering Process
Requirements Elicitation and analysis
Requirements Specification
Requirements Validation
Requirements Change
3
Requirement Engineering
• Requirements engineering is a process of gathering and defining of what the
services should be provided by the system.
• ‘user requirements’ to mean the high-level abstract requirements and ‘system
requirements’ to mean the detailed description of what the system should do.
• User Requirements: It describes the services that the system should provide
and the constrains under which it must operate. It’s usually written in a natural
language and supplied by diagrams
• The Mentcare system shall generate monthly management reports showing the
cost of drugs prescribed by each clinic during that month.
• System Requirements : are more detailed descriptions of the software
system’s functions, services, and operational constraints.
4
• The system requirements document (sometimes called a functional specification)
should define exactly what is to be implemented.
System requirements specification
• On the last working day of each month, a summary of the drugs prescribed, their
cost and the prescribing clinics shall be generated.
• The system shall generate the report for printing after 17.30 on the last working day
of the month.
• A report shall be created for each clinic and shall list the individual drug names, the
total number of prescriptions, the number of doses prescribed and the total cost of
the prescribed drugs.
• If drugs are available in different dose units (e.g. 10mg, 20mg, etc.) separate reports
shall be created for each dose unit.
• Access to drug cost reports shall be restricted to authorized users as listed on a
management access control list.
5
Functional & Non-Functional Requirements
•Functional requirements: It covers the main functions that should be provided
by the system, more specific functional system requirement describe the system
functions, it’s inputs, processing, how it’s going to react to a particular input, and
what’s the expected output.
•This is the list of the actual services which a system will provide. eg.client
demand feature software, business rules for particular organization for which
developing software.
•Non-Functional Requirements: These are constraints on the services or
functions offered by the system. They include timing constraints, constraints on
the development process, and constraints imposed by standards
•Non-functional requirements may affect the overall architecture of a system
rather than the individual components.
6
• Nonfunctional requirements arise through user needs because of budget
constraints, organizational policies, the need for interoperability with other
software or hardware systems, or external factors such as safety
regulations or privacy legislation.
• For example, functional requirements for the Mentcare system, used to
maintain information about patients receiving treatment for mental health
problems:
• A user shall be able to search the appointments lists for all clinics.
• The system shall generate each day, for each clinic, a list of patients
who are expected to attend appointments that day.
• Each staff member using the system shall be uniquely identified by
employee number.
7
Non-Functional Requirements
• Space
8
Product requirement
•The Mentcare system shall be available to all clinics during normal working
hours (Mon–Fri, 08:30–17:30).
•Downtime within normal working hours shall not exceed 5 seconds in any
one day.
Organizational requirement
•Users of the Mentcare system shall identify themselves using their health
authority identity card.
External requirement
•The system shall implement patient privacy provisions as set out in HStan-
03-2006-priv.
Figure .Examples of possible non-functional requirements for the Mentcare system
9
Domain requirements
•From the application domain of the system
•May be functional or non-functional
•Examples: Medicine, library, physics, chemistry
10
Requirements engineering processes
• Requirements engineering processes may include four high-level
activities.
• These focus on assessing if the system is useful to the business
(feasibility study), discovering requirements (elicitation and
analysis), converting these requirements into some standard form
(specification), and checking that the requirements actually define
the system that the customer wants (validation).
• Requirements engineering processes ensures your software will
meet the user expectations, and ending up with a high quality
software.
• At the end of this stage, a requirements document that specifies
11
the requirements will be produced and validated with the
Requir ements
Feasibility elicitation and
stud y
analysis
Requir ements
specification
Feasibility Requir ements
repor t validation
System
models
Requir ements
document
20
Focused ethnography
•Developed in a project studying the air traffic control process
•Combines ethnography with prototyping
•Prototype development results in unanswered questions which focus the
ethnographic analysis.
•Ethnography is helpful to understand existing systems which may have
some historical basis which is no longer relevant, but this understanding
does not always help with innovation
21
Figure 4.4. Ethnography and prototyping for requirements analysis
22
Scenarios
• Stories and scenarios are essentially the same thing. They are a description of how
the system can be used for some particular task.
• Scenarios are real-life examples of how a system can be used.
24
Use cases
•Use cases identify interactions between the system and it’s users or even
other external systems (using graphical notations), involves some
symbols to describe the system:
Actors: Are those who interact with the system; human or other systems
Interaction (Use Case): It denotes the name of the interaction (verb). It’s
represented as a named ellipse.
Connection: Lines that links between the actors and the interactions.
Include Relationship: It denotes a connection between two interactions when
an interaction is invoked by another.
Exclude Relationship: It denotes a connection between two interactions when
you want to extend an interaction by adding or optional functionality.
25
Figure 4.6. Use cases consultation for the Mentcare system
26
• Use cases identify the individual interactions between the system and its
users or other systems. Each use case should be documented with a textual
description. These can then be linked to other models in the UML that
will develop the scenario in more detail.
• The UML is a standard for object-oriented modeling, so use cases and use
case based elicitation are used in the requirements engineering process
27
ATM machine
Actors
Customers
Bank staff
ATM service engineer
Use cases
Withdraw cash
Check balance
Add cash to machine
Check security video recording
30
Requirements prioritization and negotiation
• One of the reasons is the conflicts that may arise as a result of having
different stakeholders involved. Why? because it’s hard to satisfy all
parties, if it’s not impossible.
•This activity is concerned with prioritizing requirements and finding
and resolving requirements conflicts through negotiations until you reach
a situation where some of the stakeholders can compromise.
Requirements specification
•The requirements are documented and input into the next round of the
spiral. Formal or informal requirements documents may be produced.
31
3. Requirement Specification
• Requirement specification is the process of generating requirement
document that is useful for user and system. The requirements should be
clear, easy to understand, complete and consistent.
• The user requirements for a system should describe the functional and
non-functional requirements so that they are understandable by users
who don’t have technical knowledge
• You should write user requirements in natural language supplied by
simple tables, forms, and intuitive diagrams.
32
• The system requirements on the other hand are expanded version 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. They shouldn’t be concerned with how the
system should be implemented or designed.
• The system requirements may also be written in natural language
but other ways based on structured forms, or graphical notations are
usually used.
• The most two common ways are the natural and structured
languages.
33
Natural language (informal requirements):
•The requirements are written using numbered sentences in natural language. Each
sentence should express one requirement.
Structured natural language:
•Forms/templates are used to bring some rigor to natural language presentations.
•Structured natural languages are neither formal nor graphical, and can be too much
oriented to algorithms and specific programming languages.
Graphical notations:
•Graphical models, supplemented by text annotations, are used to define the functional
requirements for the system; UML use case and sequence diagrams are commonly used.
Formal specification:
•Based on logic, state machines…
•Hard to understand for many people
34
4. Requirements Validation
•Requirements validation is a process of ensuring the specified
requirements meet the customer needs. It’s concerned with finding
problems with the requirements.
•These problems can lead to extensive rework costs when these they are
discovered in the later stages, or after the system is in service.
•The cost of fixing a requirements problem by making a system change is
usually much greater than repairing design or code errors. Because a
change to the requirements usually means the design and implementation
must also be changed, and re-tested.
•During the requirements validation process, different types of checks
should be carried out on the requirements. These checks include:
35
Validity checks: The functions proposed by stakeholders should be
aligned with what the system needs to perform, However further thought
and analysis may identify additional or different functions that are
required.
Consistency checks: Requirements in the document shouldn’t conflict or
different description of the same function.
Completeness checks: The document should include all the
requirements and constrains.
Realism checks: Ensure the requirements can actually be implemented
using the knowledge of existing technology, the budget, schedule, etc.
36
Verifiability: Can the requirements be checked?
•Requirements should be written so that they can be tested. This means you
should be able to write a set of tests that demonstrate that the system meets
the specified requirements.
Requirements 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
• Automated consistency Analysis: Checking the consistency of a
structured requirements description
37
Requirements change
• The requirements for large software systems are always changing. One
reason for the frequent changes is that these systems are often developed to
address “wicked” problems—problems that cannot be completely defined
(Rittel and Webber 1973).
• Requirements change is caused by:
• Business process changes
• Technology changes
• Better understanding of the problem
Figure 4.7. Requirements evolution
39
Requirements management planning
42
Change implementation
•The requirements document and, where necessary, the system design and
implementation, are modified.
•So, easily individual sections can be changed and replaced without
affecting other parts of the document.
Identified Revised
problem Problem analysis and Change analysis Change requirements
change specification and costing implementation
43
Thank you
44