2. Requirements Analysis
• Software engineering task bridging the gap between
system requirements engineering and software design.system requirements engineering and software design.
• Provides software designer with a model of:
• system information
• function
• behavior
• Model can be translated to data, architectural, and
component-level designs.
• Expect to do a little bit of design during analysis and a• Expect to do a little bit of design during analysis and a
little bit of analysis during design.
2
3. • The purpose of System Requirements Analysis is to obtain a
thorough and detailed understanding of the business need asthorough and detailed understanding of the business need as
defined in Project Origination and to break it down into
discrete requirements, which are then clearly defined,
reviewed and agreed upon with the Customer Decision-
Makers.
• During System Requirements Analysis, the framework for the
application is developed, providing the foundation for all
future design and development efforts.future design and development efforts.
5. Analysis Objectives
• Identify customer’s needs.
• Evaluate system for feasibility.• Evaluate system for feasibility.
• Perform economic and technical analysis.
• Allocate functions to system elements.
• Establish schedule and constraints.
• Create system definitions.
5
6.
7. • System Requirements Analysis can be a challenging phase, because all of
the major Customers and their interests are brought into the process of
determining requirements.
NEED
determining requirements.
• Since the requirements form the basis for all future work on the project,
from design and development to testing and documentation, it is of the
utmost importance that the Project Team create a complete and accurate
representation of all requirements that the system must accommodate.
• Accurately identified requirements result from effective communication
and collaboration among all members of the Project Team, and provide
the best chance of creating a system that fully satisfies the needs of the
Customers.
the best chance of creating a system that fully satisfies the needs of the
Customers.
• The primary goal of this phase is to create a detailed Functional
Specification defining the full set of system capabilities to be
implemented, along with accompanying data and process models
illustrating the information to be managed and the processes to be
supported by the new system.
8. Types of Requirements - 1
• Functional requirements:
• input/output• input/output
• processing.
• error handling.
• Non-functional requirements:
• Physical environment (equipment locations, multiple
sites, etc.).
• Interfaces (data medium etc.).• Interfaces (data medium etc.).
• User & human factors (who are the users, their skill
level etc.).
8
9. Types of Requirements - 2
• Non-functional requirements (continued):
• Performance (how well is system functioning).• Performance (how well is system functioning).
• Documentation.
• Data (qualitative stuff).
• Resources (finding, physical space).
• Security (backup, firewall).
• Quality assurance (max. down time, MTBF, etc.).• Quality assurance (max. down time, MTBF, etc.).
9
10. Requirement Validation
• Correct?
• Consistent?• Consistent?
• Complete?
• Externally - all desired properties are present.
• Internally - no undefined references.
• Each requirement describes something actually
needed by the customer.needed by the customer.
• Requirements are verifiable (testable)?
• Requirements are traceable.
10
