UNIT 2 FIRST PART AS PER INVERTIS UNIVERSITY SYLLABUS OF BCA 401

1. Presentation By
Nishu Rastogi
Assistant Professor
Invertis University, Bareilly
1

2. • Features of system or system function used to fulfill
system purpose
• Focus on customer’s needs and problem, not on
solutions
Types of Requirements-
• 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.
2

3. • The process to gather the software requirements from
client, analyze and document them is known as
requirement engineering.
• The goal of requirement engineering is to develop and
maintain sophisticated and descriptive ‘System
Requirements Specification’ document.
3

4. It is a four step process, which includes –
• Feasibility Study
• Requirement Gathering / Elicitation
• Software Requirement Specification
• Software Requirement Validation
4

5. • When the client approaches the organization with rough
idea about what functions the software must perform
• Analysts does a detailed study about whether the desired
system and its functionality are feasible to develop
• Analyzes whether the software can be practically
materialized in terms of implementation, cost constraints
and as per values and objectives of the organization
• Output of this phase is a feasibility study report that
contain comments and recommendations for
management about whether or not the project should be
undertaken.
5

6. • If the feasibility report is positive towards undertaking the
project then the next phase starts with gathering
requirements from the user.
• Analysts and engineers communicate with the client and
end-users to know their ideas on what the software
should provide and which features they want the software
to include.
• Sometimes known as Requirement gathering.
6

7. 7

8. • Requirement Gathering- The developers discuss with
the client and end users and know their expectations
from the software.
• Organizing Requirements - The developers prioritize
and arrange the requirements in order of importance,
urgency and convenience.
• Negotiation & discussion - If requirements are
ambiguous or there are some conflicts in requirements of
various stakeholders, if they are, it is then negotiated and
discussed with stakeholders. Unrealistic requirements
are compromised reasonably.
• Documentation - All formal & informal, functional and
non-functional requirements are documented
8

9. 1- Interviews
• Interviewers should be open-minded, willing to listen to
stakeholders.
• They should prompt the interviewee with a question or a
proposal.
2- Surveys
3- Questionnaires
4- Task analysis Team of engineers and developers may
analyze the operation for which the new system is
required.
5- Brainstorming- An informal debate is held among
various stakeholders and all their inputs are recorded for
further requirements analysis.
9

10. 6- Domain Analysis- Every software falls into some
domain category. The expert people in the domain can help
to analyze general and specific requirements.
7- Prototyping- is building user interface without adding
detail functionality for user to interpret the features of
intended software product. It helps giving better idea of
requirements.
8- Observation- Team of experts visit the client’s
organization or workplace. They observe the workflow at
client’s end and how execution problems are dealt. The
team itself draws some conclusions which aid to form
requirements expected from the software.
10

11. When Analyst understands the exact customer
requirement. Requirement problems are identified and
eliminated.
1- Anomaly - Ambiguity in requirement.
Ex- If the temp is high switch off heater (Threshold must be
defined).
2- Inconsistency- If requirement contradicts with each
other.
Ex- Multiple user may need different actions on some
particular condition.
3- Incompleteness- When requirements have been
overlooked.
In that case analyst suggest customer, the features
which are missing for consideration 11

12. • SRS is a document created by system analyst after the
requirements are collected from various stakeholders.
• Requirements received from client are written in natural
language
• Defines how the intended software will interact with
hardware, external interfaces, speed of operation,
response time of system, portability of software across
various platforms, maintainability, speed of recovery after
crashing, Security, Quality, Limitations etc.
• It acts as a formal (legal) document between the client
and the service provider.
12

13. • User Requirements are expressed in natural language.
• Technical requirements are expressed in structured
language, which is used inside the organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.
13

14. • Functional Requirement
• Non- Functional Requirement
• Goal of Implementation
14

15. Related to functional aspect of software such as
input/output, processing and error handling
EXAMPLES
• Search option given to user to search from various
invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be
given separate rights.
• Should comply business rules and administrative
functions.
• Software is developed keeping downward compatibility
intact.
15

16. • Consider the case of the library management system,
where
F1 : Search Book function
Input : An author’s name
Output : Details of the author’s books and the location
of these books in the library
16

17. Implicit or expected characteristics of software, which users
make assumption of.
• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Accessibility
17

18. • Easy to operate
• Quick in response
• Effectively handling operational errors
• Providing simple yet consistent user interface
18

19. 1- Introduction
a- Background
b- Overall Description
c- Environmental Characteristics
* Hardware
* Peripherals
* People
2- Goals of Implementation
3- Functional Requirements
4- Non-Functional Requirements
5- Behavioral Description
a- System States
b- Events and Actions
19

20. • Users, Customers and Marketing Personnel
To ensure them the system as described in SRS will meet
their needs.
• Software Developers
To make sure that they develop exactly what is required by
the customer.
• Test Engineers
To ensure that the requirements are understandable from
a functionality point of view, so that they can test the
software and validate its working.
20

21. • User Document Writers
To ensure that they understand the document well, to be able to
write user manuals.
• Project Managers
To ensure that they can estimate the cost easily as it contains all
the information required to plan for the project well.
• Maintenance Engineers
To understand the functionality of the system. It enables them to
determine what modifications to the system’s functionality would
be needed for a specific purpose.
21

22. • Clear (easy to understand)
• Correct
• Consistent (same everywhere no contradiction)
• Coherent (logical)
• Comprehensible (user-friendly)
• Modifiable
• Verifiable (justified)
• Prioritized
• Unambiguous (not more than one interpretation)
• Traceable
• Credible source (trusted based on facts)
22

23. • Without developing the SRS document, the system would
not be implemented according to customer needs.
• Software developers would not know whether what they
are developing is what exactly required by the customer.
• Without SRS document, it will be very much difficult for
the maintenance engineers to understand the
functionality of the system.
• It will be very much difficult for user document writers to
write the users’ manuals properly without understanding
the SRS document.
23

24. • Requirement specifications are developed, the
requirements mentioned in this document are validated
• User might ask for illegal, impractical solution or experts
may interpret the requirements incorrectly
Check following-
If they can be practically implemented
If they are valid and as per functionality and domain of
software
If there are any ambiguities
If they are complete
If they can be demonstrated
24

25. 25
Requirement Design
Describe what will be
delivered
Describe how it will be
done
Primary goal of analysis is
UNDERSTANDING
Primary goal of design is
OPTIMIZATION
There is more than one
solution
There is only one final
solution
Customer Interested Customer not interested

26. • What is the problem?
• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What exactly are the data input to the system and what
exactly are the data output by the system?
• What are the likely complexities that might arise while
solving the problem?
• If there are external software or hardware with which the
developed software has to interface, then what exactly
would the data interchange formats with the external
system be?
26

27. • A written text that accompanies computer software. It
either explains how it operates or how to use it, and may
mean different things to people in different roles.
Types of documentation
• Technical Documentation
• User Documentation
• Marketing Documentation
27

28. 28