Scribd
Upload
15 views

Software Specification and Requirements

The document discusses software requirements and specifications. It defines requirements engineering as establishing customer needs and system constraints. Requirements can range from abstract to detailed and serve different purposes. There are user requirements in natural language and system requirements that define what should be implemented. Requirements include functional requirements describing system services and non-functional requirements imposing constraints. Writing requirements is important to define the system for customers and developers.

Uploaded by

Gowthami
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
15 views

Software Specification and Requirements

The document discusses software requirements and specifications. It defines requirements engineering as establishing customer needs and system constraints. Requirements can range from abstract to detailed and serve different purposes. There are user requirements in natural language and system requirements that define what should be implemented. Requirements include functional requirements describing system services and non-functional requirements imposing constraints. Writing requirements is important to define the system for customers and developers.

Uploaded by

Gowthami
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

Software Requirement and

Specification

1
Requirements Engineering

• The process of establishing the services that the


customer requires from a system and the constraints
under which it operates and is developed.
• The requirements themselves are the descriptions of the
system services and constraints that are generated during
the requirements engineering process.

2
What is a Requirement?

• It may range from a high-level abstract statement of a


service or of a system constraint to a detailed
mathematical functional specification.
• This is inevitable as requirements may serve a dual
function
– May be the basis for a bid for a contract - therefore
must
be open to interpretation;
– May be the basis for the contract itself - therefore must
be defined in detail;
– Both these statements may be called requirements.

3
Types of Requirement

• User requirements
– Statements in natural language plus diagrams of
the services the system provides and its
operational constraints. Written for customers.
• System requirements
– A structured document setting out detailed descriptions
of the system’s functions, services and operational
constraints. Defines what should be implemented so may
be part of a contract between client and contractor.

4
User and system requirements

5
Readers of different types of requirements
specification

6
Functional and non-functional requirements
• Functional requirements
– Statements of services the system should provide, how
the system should react to particular inputs and how the
system should behave in particular situations.
– May state what the system should not do.
• Non-functional requirements
– Constraints on the services or functions offered by
the system such as timing constraints, constraints on
the development process, standards, etc.
– Often apply to the system as a whole rather than
individual features or services.
• Domain requirements
– Constraints on the system from the domain of
operation
7
Functional requirements

• Describe functionality or system services.


• Depend on the type of software, expected users and the
type of system where the software is used.
• Functional user requirements may be high-level statements
of what the system should do.
• Functional system requirements should describe the
system services in detail.

8
Functional requirements: An Example

• 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 his or her 8-digit employee number.

9
Non-functional Requirements

• These define system properties and constraints e.g.


reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
• Process requirements may also be specified mandating
a particular IDE, programming language or
development method.
• Non-functional requirements may be more critical
than functional requirements.
– If these are not met, the system may be useless.

10
Non-functional classifications

• Product requirements
– Requirements which specify that the delivered product must behave
in a particular way e.g. execution speed, reliability, etc.
• Organisational requirements
– Requirements which are a consequence of organisational policies
and procedures e.g. process standards used, implementation
requirements, etc.
• External requirements
– Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.

11
Examples of nonfunctional requirements

Product requirement
The MHC-PMS shall be available to all clinics during normal working
hours (Mon–Fri, 0830–17.30). Downtime within normal working
hours shall not exceed five seconds in any one day.

Organizational requirement
Users of the MHC-PMS system shall authenticate themselves
using their health authority identity card.

External requirement
The system shall implement patient privacy provisions as set out
in
HStan-03-2006-priv.

12
Usability requirements

• The system should be easy to use by medical staff and


should be organized in such a way that user errors are
minimized. (Goal)
• Medical staff shall be able to use all the system functions
after four hours of training. After this training, the average
number of errors made by experienced users shall not
exceed two per hour of system use. (Testable non-functional
requirement)

13
Domain Requirement

• The system’s operational domain


imposes requirements on the system.
– For example, a train control system has to take
into account the braking characteristics in
different weather conditions.
• Domain requirements be new functional
requirements, constraints on existing
requirements or define specific
computations.
• If domain requirements are not satisfied,
the system may be unworkable.
14
Requirements specification

• The process of writing don the user and system


requirements
in a requirements document.
• User requirements have to be understandable by end-
users and customers who do not have a technical
background.
• System requirements are more detailed requirements and
may include more technical information.
• The requirements may be part of a contract for the
system development
– It is therefore important that these are as complete
as possible
15

You might also like