Software Requirements

By
Engr. Dr. (Mrs)F.O. Elei
Objective and Outline
When you have read the chapter, you will
To introduce the concepts of user and system requirements

To describe functional and non-functional requirements

To explain how software requirements may be organised in a requirements document

Understand why these requirements should be written in different ways
Understand the SRS
Understand how requirements may be organized in a software requirements document.
Understand the requirement techniques.
 SOFTWARE REQUIREMENT
 SOFTWARE REQUIREMENTS ENGINEERING is the process of establishing the services that the customer requires
from a system and the constraints under which it operates and is developed. This process develops the system
definitions, establishes the consequent contractual and developer documentations and maintenance reference
for the requirement through the product lifecycle.

 The requirements themselves are the description of the system services and constraints that are generated
during the requirements engineering process.

DEFINITION OF SOFTWARE REQUIREMENTS

1. It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical
functional specification.
2. A condition or capability needed by a user to solve a problem or achieve an objective.
3. A condition or capability that must be met or possessed by a system or system component to satisfy a contract,
standard, specification, or other formally imposed documents.
 steps involved in requirement engineering
process
1. Inception, in which the nature and scope of the system is defined.
2. Elicitation, in which the requirements for the software are initially gathered.
3. Elaboration, in which the gathered requirements are refined.
4. Negotiation, in which the priorities of each requirement is determined, the essential requirements are
noted, and, importantly, conflicts between the requirements are resolved.
5. Specification, in which the requirements are gathered into a single product, being the result of the
requirements engineering.
6. Validation, in which the quality of the requirements (i.e., are they unambiguous, consistent, complete,
etc.), and the developer's interpretation of them, are assessed.
7. Management, in which the changes that the requirements must undergo during the project's lifetime are
managed.
Business Requirement

Business Requirements are the essential activities of an enterprise. Business requirements are derived from
business goals (the objectives of the enterprise or organization). Business scenarios may be used as a
technique for understanding business requirements. A key factor in the success of a system is the extent to
which the system supports the business requirements and facilitates an organization in achieving them. If
our systems and software do not support the business requirements effectively and efficiently, they have no
reason for being. Businesses exist to be profitable for stakeholders; organizations exist to meet the needs of
their members. It’s vital that we consider our systems and software development work totally within the
context of business and organizational objectives. This forms and informs the foundation for modeling
software and its requirements.
 TYPES OF REQUIREMENT
U
 USER REQUIREMENT
Statements in natural language plus diagrams of what services the system is
expected to provide and its operational constraints. Written for customers.

 SYSTEM REQUIREMENT
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
USER REQUIREMENT
•Let us assume that we have a word-processing system that does not have a spell checker. In order to be able
to sell the product, it is determined that it must have a spell checker. Hence the business requirement could
be stated as:
•User Requirement:
•Let us assume that we have a word-processing system that does not have a spell checker. In order to be able
to sell the product, it is determined that it must have a spell checker. Hence the business requirement could
be stated as:
user will be able to correct spelling errors in a document efficiently.

Hence, the Spell checker will be included as a feature in the product

User requirement
Should describe functional and non-functional requirements in such a way that they are
understandable by system users who don’t have detailed technical knowledge.

• User requirements are defined using natural language, tables and diagrams as these can be
understood by all users.
• t 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 may arise from factors which are external to the system and its development process e.g.
interoperability requirements, legislative requirements, etc.
Guideline for writing user requirements
To minimise misunderstandings when writing user requ
• Invent a standard format and use it for all requirements.

• Use language in a consistent way. You should always distinguish

between mandatory and desirable requirements.

• Use text highlighting to identify key parts of the requirement.

• Avoid the use of computer jargon.

System Requirement:

After documenting the user’s perspective in the form of user requirements,

the system’s perspective: what is the functionality provided by the system
and how will it help the user to accomplish these tasks. Viewed from this
angle, the functional requirement for the same user requirement could be
written as follows:
The spell checker will find and highlight misspelled words. Right clicking a
misspelled word, will then display a dialog box with suggested
replacements. The user will be allowed to select from the list of suggested
replacements. Upon selection it will replace the misspelled word with the
selected word. It will also allow the user to make global replacements.
Functional and Non functional Requirements
• 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.

• Non-functional requirements (Quality Requirements)

• NON FUNCTIONAL (Quality ) REQUIREMENTS
Constraints on the services or functions offered by the system such as timing constraints, constraints on the
development process, standards, etc.
requirements
FUNCTIONAL REQUIREMENTS

• Functional user requirements may be high-level statements of what

the system should do but functional system requirements should
describe the system services in detail
• Functional requirements: The functional requirements discusses the
functionalities required from the system. The system is considered to
perform a set of high level functions {fi}.
EXAMPLE AN ONLINE LIBSYS used by students/ staffs
to order for books and documents from the library
• A library system that provides a single interface to a number of databases of
articles in different libraries.

• Users can search for, download and print these articles for personal study.

• The user shall be able to search either all of the initial set of databases or
select a subset from it.

• The system shall provide appropriate viewers for the user to read
documents in the document store.
ROLE OF FUNCTIONAL REQUIREMENT
• It documents what the customer expects to be delivered and provide
the contractual basis for the development
• To the managers, it may provide the basis for scheduling a yardstick
for progress
• To software engineer, it specified the constraint on behaviour and
performance.
• To developer, it defines the range of acceptable system behaviour and
is the final authority on the outputs produced.
• To tester, it is the basis for test planning and verification.
NON-FUNCTIONAL REQUIREMENTS

• Non-functional requirements may be more critical than functional requirements. If these are not met, the
system is useless.
Non-Functional requirements: Nonfunctional requirements deal with the characteristics of the system which
cannot be expressed as functions - such as the maintainability of the system, portability of the system,
usability of the system, etc.
• These define system properties and constraints e.g. reliability, response time and storage
requirements,accuracy of results, human - computer interface, constraints on the system implementation,
etc.

• They may define constraints on the system such as the capabilities of I/O devices and the data
representations used in system interfaces.

• Process requirements may also be specified mandating a particular CASE system, programming language or
development method.
System requirement
• More detailed specifications of system functions, services and constraints than user
requirements.

• They are intended to be a basis for designing the system.

• They add detail and explain how the user requirements should be provided by the
system.

• The system requirements should simply describe the external behaviour of the system
and its operational constraints.

• They should not be concerned with how the system should be designed or
implemented.
User requirement / user storey scenario
• 3w criteria(who,why,what)
• Acceptance criteria
• Test criteria
USER STORY
• User story is a requirement expressed from the perspective of an end-user goal.it defines the req in a lag
that has meaning to the role.it helps to bring out real objectives of the project
• For example: as a human res manager, HRM, I need a better way to deal with the employer records,so that
employee history can be tracked including their training and carrier moves.
• Other than
• An organization will implement a human resources system.
The front card
• Who is the primary stakeholder
• What effect the stakeholder want the story to have
• What bus valve the stakeholder will derive from this effect

The back card

• Acceptance cases that will be use as basic for test
Test criteria will confirm that this user story is working as required
• Acceptance is use to describe the aim and sometimes the behavior of
the system.for example
• Has speed of dispatch improved to within 24hrs of time of order for
99%of instock items within 6 months
• Functional examples of acceptance criteria
• Can I save my order and come back to it later?
• Can I change my order before I pay for it
• Can I see a running total of the cost of what I have choosen
Non Functional Requirement
• Availability
• Can I placed an order at any time i.e 24 hour at any time to the point
of delivery
• Can I receive feedback at any time
• Security

• Are unauthorized persons and other customers prevented from

viewing my order.
Concept in Requirement
• Context diagram: A diagram of the product and its surroundings. It shows the
scope of the product. The context diagram shows the product as a black box
surrounded by user groups and external systems with which it communicates.
Arrows show how data flow between the product and its surroundings.
Use Case
• Use case: use case is primarily the product’s part of a task, including its
interaction with the user. Although widely used for analysis and design, most
kinds of use cases are on a too detailed level to be used as domain-level
requirements, because they specify parts of the user interface design. However,
some kinds of use cases are suited as product-level requirements and for
designing the detailed user dialog.
Use case example
Event & function lists
• Event & function lists: An event is something that requests a system to perform
some function. Usually an event arrives with some data telling the system what
to do. An event list shows the types of events that can arrive at the system. Since
an event causes the system to perform a function, we can make a similar list of
the functions that the system can perform.
Event & function lists example
Case Scenarios
Case Scenarios: For requirements purposes, it either means a small story with a vivid illustration of the work
area, or a specific case of a task. UML defines scenarios as an instantiation of a use case. This means that a task
description (use case) is the general pattern for doing certain things, while a scenario is how it is done in one
particular case. We will call this kind of scenario case scenarios.
• Here are some simple examples:
• Checking in a guest is a task (the general case – any guest).
• Checking in John Simpson who has booking number 2533 is a case scenario.
• The evening duty is a vivid scenario.
• Checking in Sheik Ibrahim and his three wives and six children is a case scenario that happens to
be vivid at the same time.
• Screens & prototypes: Under certain circumstances it is an excellent idea to design the final screen sketch and
specify that they are requirements. Doing this goes much further in the design direction than specifying
features.
Software Requirement Specification(SPS)
• The final product of Requirement Engineering is Software
requirement specification(SPS).
• It contains a complete description of the functionality of the system.
• It contain both functional and non-functional requirements.
• Contains all the software requirements, diagrams,system models and
other supporting information.
• It is the end result of the analysis phase
• It is the end result of the requirements analysis phase
• It also serves as a baseline for the downstream phases.
Characteristics of SRS
• Correctness
• unambiguous
• Completeness
• Verifiable
• Consistent
• Feasibility
• Modifiable
• Traceability
Requirement Management
• Is a set of activities that help to learn, identifies, control and track
requirement and changes at any time.
• It focuses on basic fundamental activities of documentation and
traceability
• Builds dialogue and accountability
• Manages changes to requirements and inconsistencies between
requirements, work products and plans.
Software elicitation
• Software elicitation techniques are used to obtain the stakeholder
information, knowledge and needs (not their wants) to develop
quality software. It gives the knowledge of the application domain, of
the context, and the problems solved by the software .
Techniques of software elicitation
• Stakeholders Analysis
• Design/ brainstorming workshops
• Prototyping
• Pilot experiments
• cost benefit and risk analysis
Brainstorming
• Brainstorming is the process of discovering and documenting the needs and expectation of
the stakeholders for the software system design. It is creative and collaborative technique
that involves generating as many ideas as possible in a short time without judging or
evaluating them. The goal is to explore different perspectives, stimulate creativity and
identify potential solutions or requirements.
• Pros

• It helps uncover hidden or implicit requirement requirement and foster good atm among
participant
• It encourages sharing of diverse ideas, knowledge and experience allowing the creation of
novel and creative solutions
• It can stimulate innovation by encouraging participant to think outside the box
• To invent new way of doing things or when much is unknown
• When there are few or too many ideas
• Early on in a project particularly when:
• Terrain is uncertain
• There is little expertise for the type of applications
• Innovation is important (e.g., novel system)
• Two main activities:
• The Storm: Generating as many ideas as possible (quantity, not quality) – wild is good!
• The Calm: Filtering out of ideas (combine, clarify,
prioritize, improve…) to keep the best one(s) –
may require some voting strategy
• Roles: scribe, moderator (may also provoke),
participants
interview
• Interviews can be conducted with stakeholders and experts to gain a
better understanding of their needs and expectations
• Functional requirements
• What will the system do?
• When will the system do it?
• Are there several modes of operations?
• What kinds of computations or data transformations must be performed?
• What are the appropriate reactions to possible stimuli?
• For both input and output, what should be the format of the data?
• Must any data be retained for any period of time?
Interview question
• Design Constraints
• Physical environment
• Where is the equipment to be located?
• Is there one location or several?
• Are there any environmental restrictions, such as temperature, humidity, or magnetic interference?
• Are there any constraints on the size of the system?
• Are there any constraints on power, heating, or air conditioning?
• Are there constraints on the programming language because of existing software components?
• Interfaces
• Is input coming from one or more other systems?
• Is output going to one or more other systems?
• Is there a prescribed way in which input/output need to be formatted?
• Is there a prescribed way for storing data?
• Is there a prescribed medium that the data must use?
• Standards
• Are there any standards relevant to the system?
Survey and questionnaires/pilot experiment
• Questionnaire's: Used to collect qualitative or quantitative data from
a large number of users. Piolt experiment : is a small scale-study
conducted prior to conducting an actual experiment; designed to test
and refine procedures.
• Example: asking people to fill/complete a survey to find out whether a
question results in the requested information.
Observation and prototying
• Obervation of how stakeholder react to a prototyped design can help
identify problems, challenges or opportunities for improvement.
• The principal use of prototyping is to help customers and developers
understand the requirements for the system
• Requirements elicitation. Users can experiment with a prototype to see how
the system supports their work
• Requirements validation. The prototype can reveal errors and omissions in
the requirements
• Prototyping can be considered as a risk reduction activity which
reduces requirements risks
Prototyping contd

• Improved system usability Establish Define

Develop Evaluate
prototype prototype
• Closer match to the system needed objectives functionality
prototype prototype

• Improved design quality Prototyping

plan
Outline
definition
Executable
prototype
Evaluation
report

• Improved maintainability
• Reduced overall development effort

• Evolutionary prototyping
• An approach to system development where an initial prototype is produced
and refined through a number of stages to the final system
• Throw-away prototyping
Scenarios/ use cases
• it can be created to illustrate the requirements in a concrete and
realistic way.
• Create a set of use cases/ Scenarios to identify a thread of usage for
the system.
• It provide description of how the system will be used.
Cost analysis and risk analysis in requirement
development

• Risk elicitation techniques identify strengths, weakness, opportunity and

threats One of the most common risks in requirements elicitation is missing
or omitting some important requirements that are essential for the project's
success. This can happen due to various reasons, such as lack of stakeholder
involvement, unclear project scope, insufficient research, or inadequate
documentation. To
• A cost-benefit analysis is a process that helps you determine the economic
benefit of a decision, so you can decide whether it’s worth pursuing. It’s a
useful tool when you want to avoid bias in your decision-making process—
especially when you’re faced with a big decision that will impact your team or
project success.