Scribd
Upload
9 views

Session 3

The document discusses software engineering requirements, including: 1. Understanding the concepts of functional and non-functional requirements. Functional requirements describe what a system should do, while non-functional requirements constrain how it operates. 2. Requirements engineering involves eliciting, analyzing, documenting, and validating requirements through activities like writing a software requirements document. 3. A software requirements document specifies both user and system requirements, and is important for communication between developers and customers. It includes requirements, validation processes, and management of changes.

Uploaded by

Isaac Kariuki
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
9 views

Session 3

The document discusses software engineering requirements, including: 1. Understanding the concepts of functional and non-functional requirements. Functional requirements describe what a system should do, while non-functional requirements constrain how it operates. 2. Requirements engineering involves eliciting, analyzing, documenting, and validating requirements through activities like writing a software requirements document. 3. A software requirements document specifies both user and system requirements, and is important for communication between developers and customers. It includes requirements, validation processes, and management of changes.

Uploaded by

Isaac Kariuki
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Software Engineering

Requirement Engineering
• understand the concepts of user and system requirements and why
these requirements should be written in different ways;
• understand the differences between functional and nonfunctional
software requirements;
• understand how requirements may be organized in a software
requirements document;
• 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
• The requirements for a system
– the descriptions of what the system should do, the
services that it provides and the constraints on its
operation.
– requirements engineering (RE).
• The process of finding out, analyzing, documenting and
checking these services and constraints.
Types

1. Functional requirements
– These are statements of services the system should provide, how the
system should react to particular inputs, and how the system should
behave in particular situations. In some cases, the functional requirements
may also explicitly state what the system should not do.
2. 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.
Functional requirements
• Describe what the system should do
• i.e in a mental health patient management system

1. A user shall be able to search the appointments lists for all clinics.
2. The system shall generate each day, for each clinic, a list of patients who
are expected to attend appointments that day.
3. Each staff member using the system shall be uniquely identified by his or
her eight-digit employee number.
• F.R should be
– Complete- means that all services required by the user should be defined.
– Consistent -means that requirements should not have contradictions
• Challenges
– Possibility to make mistakes and omissions when writing specifications for
complex systems.
– Many stakeholders in a large system
Non-functional requirements

• are requirements that are not directly concerned with the specific
services delivered by the system to its users.
• They may relate to emergent system properties such as reliability,
response time, and store occupancy, performance, security, or
availability.
Metrics for specifying non-functional requirements
Types of non-functional requirement
• Product requirements
– These requirements specify or constrain the behavior of the software.
Examples include performance requirements on how fast the system must
execute and how much memory it requires, reliability requirements that set
out the acceptable failure rate, security requirements, and usability
requirements.
• Sample-The MHC-PMS shall be available to all clinics during normal
working hours (Mon–Fri, 08.30–17.30). Downtime within normal
working hours shall not exceed five seconds in any one day
• Organizational requirements
– These requirements are broad system requirements derived from policies
and procedures in the customer’s and developer’s organization. Examples
include process standards.
• Sample-Users of the MHC-PMS system shall authenticate themselves
using their health authority identity card.
Cont’
• External requirements
– This broad heading covers all requirements that are derived from factors
external to the system and its development process. i.e systems is approved for
use by a regulator, such as a central bank; legislative requirements that must be
followed to ensure that the system operates within the law; and ethical
requirements that ensure that the system will be acceptable to its users and the
general public.
• The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.
The software requirements document

• is an official statement of what the system developers should


implement.
• It should include both the user requirements for a system and a
detailed specification of the system requirements.
• essential when an outside contractor is developing the software
system.
Users of a requirements document
Format
Includes
• Requirements specification
– is the process of writing down the user and system equirements in a
requirements document. Ideally, the user and system requirements
• Requirements validation
– Requirements validation is the process of checking that requirements actually
define the system that the customer really wants.
Types of Checks
• Validity checks
– A user may think that a system is needed to perform certain functions.However,
further thought and analysis may identify additional or different functions that
are required.
• Consistency checks
– Requirements in the document should not conflict. That is, there should not be
contradictory constraints or different descriptions of the same system function.
• Completeness checks
– The requirements document should include requirements that define all
functions and the constraints intended by the system user.
• Realism checks
– Using knowledge of existing technology, the requirements should be checked to
ensure that they can actually be implemented within budget and schedule.
• Verifiability
– To reduce the potential for dispute between customer and contractor,. you
should be able to write a set of tests that can demonstrate that the delivered
system meets each specified requirement
Requirements management
• is the process of understanding and controlling changes to system
requirements.
• Reason
– The business and technical environment of the system always changes after
installation. New hardware may be introduced, it may be necessary to interface
the system with other systems.
– The people who pay for a system and the users of that system are rarely the
same people
– Large systems usually have a diverse user community

You might also like