UNIT - II

1. Software Requirements:
i. Functional and non-functional requirements
ii. user requirements
iii. System requirements,
2. interface specification AND software requirements document.
3. Requirements engineering process:
i. Feasibility studies
ii. requirements elicitation and analysis,
iii. requirements validation
iv. requirements management.
4. System models:
i. Context models
ii. behavioral models
iii. data models
iv. object models
v. structured methods.

Non Functional
Functional Requirements Requirements
A non-functional
requirement defines the
A functional requirement defines a system or its quality attribute of a
component. software system.
It places constraints on
“How should the software
It specifies “What should the software system system fulfill the
do?” functional requirements?”
Non-functional
requirement is specified
by technical peoples e.g.
Architect, Technical
leaders and software
Functional requirement is specified by User. developers.

It is mandatory. It is not mandatory.

Helps you to verify the
performance of the
Helps you verify the functionality of the software. software.
Non-Functional Testing
like Performance, Stress,
Functional Testing like System, Integration, End Usability, Security
to End, API testing, etc are done. testing, etc are done.
 Usually more difficult to
Usually easy to define. define.

Example Example
1) Emails should be sent
with a latency of no
1) Authentication of user whenever he/she logs greater than 12 hours
into the system. from such an activity.
2) The processing of
each request should be
2) System shutdown in case of a cyber attack. done within 10 seconds
3) The site should load in
3) A Verification email is sent to user whenever 3 seconds when the
he/she registers for the first time on some number of simultaneous
software system. users are > 10000

Types of requirement:
 User requirements
User requirements, often referred to as user needs, describe what the user
does with the system, such as what activities that users must be able to
perform.
The MHC-PMS shall generate monthly management reports showing
the cost of drugs prescribed by each clinic during that month.

 System requirements
o 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.
System Requirements Specification:

1.1. On the last working day of each month, a summary of the drugs
prescribed, their cost, and the prescribing clinics shall be generated.
INTERFACE SPECIFICATION
Three types of interface may have to be defined
• Procedural interfaces it Is used for calling the existing programs by the new programs These interfaces are
sometimes called Application Programming Interfaces (APLs).
• Data structures that are passed from one sub-system to another. Graphical data models are the best notations for
this type of description
• Data representations that have been established for an existing sub-system

5) THE SOFTWARE REQUIREMENTS DOCUMENT:

 The requirements document is the official statement of what is required of the system developers.
 Should include both a definition of user requirements and a specification of the system requirements.
 It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it
should do it

Users of a requirements document: IEEE requirements standard defines a generic structure for a requirements
document that must be instantiated for each specific system.
1. Introduction.
i) Purpose of the requirements document
ii) Scope of the project
iii) Definitions, acronyms and abbreviations
iv) References
v) Overview of the remainder of the document
2. General description.
i) Product perspective
ii) Product functions
iii) User characteristics
iv) General constraints
v) Assumptions and dependencies
3. Specific requirements cover functional, non-functional and interface requirements. The requirements may
document external interfaces, describe system functionality and performance, specify logical database requirements,
design constraints, emergent system properties and quality characteristics.
4. Appendices.
5. Index.
REQUIREMENTS ENGINEERING PROCESSES

1) FEASIBILITY STUDIES
 A feasibility study involves information assessment, information collection and report writing.
 In the report, you may propose changes to the scope, budget and schedule of the system and suggest further
high-level requirements for the system.
2) REQUIREMENT ELICITATION AND ANALYSIS:
 Sometimes called requirements elicitation or requirements discovery.
 Involves technical staff working with customers to find out about the application domain, the services that
the system should provide and the system’s operational constraints.
 May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.
These are called stakeholders.
 Requirement discovery is the process of gathering information about the proposed and existing systems
 For example, system stakeholder for a bank ATM include
 1. Bank customers
 2. Representatives of other banks
 3. Bank managers
  4. Counter staff
 5. Database administrators
 6. Security managers
 7. Marketing department
 8. Hardware and software maintenance engineers
 9. Banking regulators

3) REQUIREMENT SPECIFICATION

4) REQUIREMENTS VALIDATION

Requirements checking:
• Validity: Does the system provide the functions which best support the customer’s needs?
• Consistency: Are there any requirements conflicts?
• Completeness: Are all functions required by the customer included?
• Verifiability: Can the requirements be checked?

System models:
1. Context models
2. behavioral models
3. data models
4. object models
5. structured methods.

Five types of UML diagrams that are the most useful for system modeling:

 Activity diagrams, which show the activities involved in a process or in data processing.

 Use case diagrams, which show the interactions between a system and its environment.
 Sequence diagrams, which show interactions between actors and the system and between
system components.
 Class diagrams, which show the object classes in the system and the associations between these
classes.
 State diagrams, which show how the system reacts to internal and external events.

1. Context models:-
Context models are used to illustrate the operational context of a system - they show what lies outside the system
boundaries.
2) BEHAVIOURAL MODELS:
 Behavioural models are used to describe the overall behaviour of a system.
 Two types of behavioural model are:
o Data processing models that show how data is processed as it moves through the system;
o State machine models that show the systems response to events.

Data flow diagrams (DFD)

STATE MACHINE MODELS

3) SEMANTIC DATA MODELS:
 Used to describe the logical structure of data processed by the system.
 An entity-relation-attribute model sets out the entities in the system, the relationships between these entities and
the entity attributes
 Widely used in database design. Can readily be implemented using relational databases.
 No specific notation provided in the UML but objects and associations can be used.
4) OBJECT MODELS:

Object models describe the system in terms of object classes and their associations.
 An object class is an abstraction over a set of objects with common attributes and the services (operations)
provided by each object.
 Various object models may be produced
o Inheritance models;
o Aggregation models
Inheritance models:
 Organise the domain object classes into a hierarchy.
 Classes at the top of the hierarchy reflect the common features of all classes.
 Object classes inherit their attributes and services from one or more super-classes. these may then be specialised
as necessary.
Object aggregation:
 An aggregation model shows how classes that are collections are composed of other classes.
 Aggregation models are similar to the part-of relationship in semantic data models.

5) STRUCTURED METHODS:

 Structured methods incorporate system modeling as an inherent part of the method.

 CASE tools support system modeling as part of a structured method.

Analysis CASE tools workbench components:

 Diagram editors
 Model analysis and checking tools
 Repository and associated query language
 Data dictionary
 Report definition and generation tools
 Forms definition tools
 Import/export translators
 Code generation tools