Requirements Analysis

Chapter 2
Requirements
Information which describes user’s expectation about system
performance
Must be clear and unambiguous (Single word with different meaning)
Characteristics of Requirements
• Unambiguous (not confusing) • Feasible (realistic, possible)
• Testable (verifiable) • Independent
• Clear (concise, terse, simple, • Atomic
precise) • Necessary
• Correct • Implementation-free (abstract)
• Understandable
Types of Requirement
Functional Requirements
describe all those functions needed to implement to achieve the
goals of business and users
include features such as sorting goods by price, manufacturer,
materials, etc., or the ability to multi-factor authentication to achieve
the highest possible level of system security.
Functional requirements examples
1. Set data access levels; for example, income data inside the system
should be available only to users at the Administrator/Editor level
2. Automatic customer verification for compliance with ABC contact
management system
3. Integration of software with banking API
4. Ability to record sales in the sales system
Non-functional Requirements
does not describe the product's functions, but it does describe the
properties and rules to which it must comply.
For example, there is a multifactor authentication function. Its
attribute is the required number of characters in the password - for
example, 10, where the numbers and underscores are allowed.
Types of Non-functional Requirement
Product Requirement
Requirement which mention delivered product should have behavior in
specific way e.g.. Execution speed, reliability, etc.
Organizational Requirement
Result of organizational policies and procedures
External Requirement
Generated from the factors that are external to the system and its
development process
Examples
The primary password cannot be reused.
Users must change the originally given password immediately after
the first successful login.
Every user’s attempt to access the system component must be
recorded in the audit trail.
the site should be loaded in 3 seconds, the number of users at a time
should be 10 000.
Domain Requirement
Domain requirements are expectations related to a particular type of
software, purpose or industry vertical.
Domain requirements can be functional or nonfunctional.
The common factor for domain requirements is that they meet
established standards or widely accepted feature sets for that category
of software project.
typically arise in military, medical and financial industry sectors,
among others.
Requirement Engineering
The process to gather the software requirements from client, analyze
and document them is known as requirement engineering.
Goal: to develop and maintain sophisticated and descriptive ‘System
Requirements Specification (SRS)’ document.
Requirement Engineering Process
Phases:
Feasibility Study
Requirement Elicitation and Analysis
Software Requirement Specification
Software Requirement Validation
Software Requirement Management
1. Feasibility Study
Objectives of feasibility study is:
 to create the reasons for developing the software that is acceptable to
users
flexible to change
conformable to established standards.
Types of Feasibility
Technical Feasibility - Technical feasibility evaluates the current
technologies, which are needed to accomplish customer
requirements within the time and budget.
Operational Feasibility - Operational feasibility assesses the
range in which the required software performs a series of levels
to solve business problems and customer requirements.
Economic Feasibility - Economic feasibility decides whether the
necessary software can generate financial profits for an
organization.
2. Requirement Elicitation and Analysis
also known as the gathering of requirements
requirements are identified with the help of customers and existing
systems processes
analyzed to identify inconsistencies, defects, omission, etc.
Analysis of requirements starts with requirement elicitation
Elicitation Methods
Interviews
Surveys
Questionnaire
Task analysis
Domain analysis
Brainstorming
Prototyping
Observation
Problems of Elicitation and Analysis

Getting all, and only, the right people involved.

Stakeholders often don't know what they want
Stakeholders express requirements in their terms.
Stakeholders may have conflicting requirements.
Requirement change during the analysis process.
Organizational and political factors may influence system
requirements.
3. Software Requirement Specification
kind of document which is created by a software analyst after the
requirements collected from the various sources
requirement received by the customer written in ordinary language
analyst should write the requirement in technical language for
development team
include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.
Data Flow Diagrams
flow of data through a system
Data Dictionaries
store information about all data items defined in DFDs
Entity-Relationship (ER) Diagrams
detailed logical representation of the data for the
organization and uses three main constructs i.e. data entities,
relationships, and their associated attributes.
4. Software Requirement Validation
requirements discussed in SRS document are validated
user might demand illegal, impossible solution or experts may
misinterpret the needs. Requirements can be the check against the
following conditions
1. If they can practically implement
2. If they are correct and as per the functionality and specially of
software
3. If there are any ambiguities
4. If they are full
5. If they can describe
Requirements Validation Techniques
Requirements reviews/inspections: 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 for the consistency of
structured requirements descriptions.
5. Software Requirement Management
Requirement management is the process of managing changing
requirements during the requirements engineering process and system
development.
New requirements emerge during the process as business needs a
change, and a better understanding of the system is developed.
The priority of requirements from different viewpoints changes during
development process.
The business and technical environment of the system changes during
the development.
Software Prototyping
Software prototypes refers to working models of software with
limited functionality.
 no exact logic used in actual software application.
It also provides an opportunity for the manufacturer to get an actual
feel of what the final product will look like before additional
resources, like time and money, are put into finalizing the product.
Software Prototyping
Process
1. Basic Requirement Identification
understanding the basic product requirements

2. Developing The Initial Prototype

consider the requirements, begin to assemble

3. Review Of The Prototype

feedback is collected

4. Revising The Prototype

revisions to the prototype
Types of software prototyping models
Throwaway/rapid prototyping
Rapid prototyping is also known as throwaway prototyping because
prototypes are only fit for brief periods of time.
Pass through various feedback, revision, and assessment cycles
When all collaborators are satisfied, it becomes the standard for
designers and developers to apply.
Once the exact conditions are noted, the prototype is rejected and the
actual system is developed
Extreme prototyping
Extreme prototyping is mainly applied for web development.

All pages are available in HTML format in the basic prototype.

A service class prototype is used to stimulate the data process.
In the last step, all the processes are performed and connected with the
final prototype.
 Evolutionary prototyping
• Evolutionary prototypes are
created by the team in an
incrementally refined manner
after accepting the customer’s
final feedback.
• useful when the software
requirement is not understood
perfectly
Incremental Prototyping
Software Documentation
Software documentation helps you to understand the product,
interface, capability, ability to fulfill a task, and quickly search and
find a particular section within the document, or find resolution when
encountered using the product.

Types of Software Documentation

1. User Documentation
2. Developer Documentation
Characteristics of S/W documentation
Correct
Unambiguous
Complete
Ranked for importance/stability
Modifiable
Traceable
Verifiable
User Documentation
How-to guides Guides the user to complete a task or a
predetermined goal.
Tutorials Learns a concept by following a series of steps
concept
Reference docs technical detail of the product
Administration Enables the administrator to refer to this after
Guide installing an application
Configuration Allows the administrator to refer to this document
Guide for configuration parameters.
Developer Documentation
API (Application Programing Interface)
documentation Specifies how to invoke API calls and classes, or how to
include API in the code that is being developed.

Release notes Describes about the latest software, feature releases, and
what bugs have been fixed with (.txt)

README simple plain text file called Read Me, READ.ME,

README.TXT with A high-level overview of the software,
usually alongside the source code.

System Describes the system requirements, includes design

documentation documents and UML diagrams.
Just-in-time Documentation
just-in-time document quickly serves the support for customer-facing
documentation.
The user need not have to refer to any documents or FAQs for
information.
 For example, GitHub is a cloud-based do my papers application,
which serves the purpose for code developers and authors.
Creating software documentation
Understand user needs
Write easily understood documentation
Include internal subject matter experts
Use analytics feedback
Ask for user feedback
Provide continuous maintenance
Software documentation Tools
Apiary
APIMatic
GitHub Pages
ReadMe
Stoplight
Swagger
Advantage of software documentation
keeping the track of all aspects of an application and also improves on the
quality of the software product
main focus are based on the development , maintenance and knowledge
transfer to other developers.
Helps development teams during development.
Helps end-users in using the product.
Improves overall quality of software product
It cuts down duplicative work.
Makes easier to understand code.
Helps in establishing internal co-ordination in work.
Disadvantage of software documentation
documenting code is time consuming.
The software development process often takes place under time
pressure, due to which many times the documentation updates don’t
match the updated code .
The documentation has no influence on the performance of the an
application.
Documenting is not so fun, its sometime boring to a certain extent.
Software Requirements Specification
(SRS)
A software requirements specification (SRS) is a document that
describes what the software will do and how it will be expected to
perform.
It also describes the functionality the product needs to fulfill all
stakeholders (business, users) needs.
Format of SRS
1. Introduction
Purpose – for whom SRS is constructed
Scope – for which SRS is built
Definition, acronyms, abbreviation – to avoid ambiguities in
requirements
References – refereed by this document
Overview – goals and objectives of System
2. The overall Description
Product perspective - benefits of current product over existing
product
Product function – functionality of system
User characteristics – basic knowledge of system
Constraint – limitations of the component
Assumption and dependencies – SRS dependencies
Apportioning of requirements – order in which the requirements are
fulfilled
3. Specific Requirement
Interfaces – specifies interfaces of hardware, software, system, user
communication
Databases – to store data required and generated by system
Performance – describes required speed, task completion time,
response time and throughput of the system
Software system attributes – assurance of reliability, security,
maintainability
4. change Management Process
Helps to handle all kind of additional changes done by user

5. document approvals
Approval from customers and developer, approval date time and sign

6. Supporting Information
Guidelines about how to use SRS, index of SRS, references, etc.
HOMEWORK
SRS on hospital management system
SRS on online student feedback system
Requirement Elicitation Process
Benefits
Lower project costs by catching requirements problems before
development begins.
Increase the likelihood that users and customers get what they want.
Reduce the risk of project failure.
Steps
Gathering requirements
Identifying key stakeholders
Eliciting requirements from key stakeholders
Documenting requirements
Confirming the findings
Different ways to identify customer
requirement
Interviews
Surveys
Questionaries
Task analysis
Domain analysis
Brainstorming
Prototyping
Observations