Scribd
Upload
10 views22 pages

Requirements

Uploaded by

anuragsisodiya2121
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views22 pages

Requirements

Uploaded by

anuragsisodiya2121
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 22

Requirements

Why are requirements are important


• 68% of projects with effective communication, and precise
requirements, are likely to deliver project scope and meet
quality standards successfully.
• At the same time, 32% of IT projects failed due to sparse
estimation during the planning phase and unclear
requirements.
• Besides, unclear requirements increase the project timeline and
budget up to 60%.
• Also, unclear requirements consume over 41% of the IT
development budget for software, staff, and external
professional services.
Categories of Requirements
• Functional Requirements
• Non-Functional Requirements
• User Requiremets
• System Requirements
Functional Requirements
• Functional requirements are statements that
• 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.
Examples of Functional Requirements
• Functional Requirements for a college library
• 1. There shall be a search by which the users shall be able search the
required books, journals, magazines
• 2. The system shall generate reports required by students, library staff
for the various status of books, journals and magazines.
• 3. The systems shall have an option by which the new books can be
added into the library
• 4. The system shall have an option to discard books which have not in
proper condition.
What are considered to be good requirements.

• The requirements should exhibit the following properties


• 1. Completeness
• The requirements should be expressed completely
• 2. Unambiguous
• There should clarity about the requirements, there should be proper
expression of requirements.
• 3. Consistent
• The explantion of the requirements should not keep changing
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.

Reference : IAN Sommerville 9th Edition Pearson Publication


Example of Non-Functional Requirements
• Performance of the search in the library software, ie time taken for
the query to fetch, update, delete records
• Throughput of the search can be stated as the number of records of
books that might be searched, updated, deleted.
• Security may be stated as the how secure is the software, ie no of
vulnerabilities that are covered
User Requirements
• User requirements are statements which state the functions that are
performed by the users of the software. So we should have a list of
users who use the software for performing their work
• The library staff.
System Requirements
• The hardware and software, required to deploy the software and hve
it working.
Requirements and SDLC
• Requirements are finalized in an iterative manner in the RUP model of
software development.
Steps for gathering requirements
• Five important activities in this phase
• Requirement eliciting,
• Requirements expressing,
• Requirements prioritizing,
• Requirements analyzing, and
• Managing requirements.
Requirements Eliciting
• Requirements elicitation is the practice of researching and
discovering the requirements of a system from users,
customers, and other stakeholders.
• Methods
• 1. Questionnaires
• 2. Interviews
• 3. Ethanography
• 4. Prototype
Requirements Expressing
• Data Flow Diagram
• Data Flow Diagram is a network representation of a system
• This representation is often used in the analysis of the requirements
(e.g. business flow).
• From the initial diagram one may refine the diagram and portray
deeper levels of the system.
• It has 4 basic elements :
• Source or Destination of Data
• Flow of Data
• Process which transforms Data
• Store of Data
• Reference:
Example of DFD

Inventory Info.
Package Data
Item
Product avail.
Search Packaging
Info.
info details
Shipping
Orders Order Instruct. Packaging
Customer Processing
Order
Confirmation
Invoice
Customer credit,
cust. address, etc.
query
Customer
info

Customer Info DB
Activity Diagram
Use case
Requirements and users goals
• Non-functional requirements may be very difficult to state precisely and
imprecise requirements may be difficult to verify.
• Goal
• A general intention of the user such as ease of use.
• Verifiable non-functional requirement
• A statement using some measure that can be objectively tested.
• Goals are helpful to developers as they convey the intentions of the system users.
Different ways to write 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)
Metrics for Nonfunctional Requirements
Keypoints
• Requirements for a software system set out what the system should
do and define constraints on its operation and implementation.
• Functional requirements are statements of the services that the
system must provide or are descriptions of how some computations
must be carried out.
• Non-functional requirements often constrain the system being
developed and the development process being used.
• They often relate to the emergent properties of the system and
therefore apply to the system as a whole.
References
• IAN Sommerville 9th Edition Pearson Publication

You might also like