SE Module 2 and 3

Software Engineering (22BCA3C01)
Module 2 and 3
Software Requirements
Syllabus of the Modules
Module-2
Understanding Requirements (09 Hours): What are Software Requirements? Characteristics of
Good Requirements, Functional and Non-Functional Requirements, Requirements Engineering
Process: Feasibility Studies, Elicitation, Specification, Validation; Software Requirements
Specification (SRS) document, IEEE Guidelines.
Module-3
Requirements Modelling (09 Hours)- Scenario-Based Modeling: Use-Case Model, Use Case
Specification, Activity Diagram; Class-Based Modeling: Identifying Analysis Classes, CRC Model,
Association and Dependency, Class Diagram; Behavior Modeling: State Diagram, Sequence
Diagram, and Collaboration Diagram; Data Modeling: E-R Diagram, Mapping E-R diagram to
Relational Model.
3rd Semester, Dept. of BCA 1

What are Software Requirements?

The requirements for a software system are descriptions of the services / functionalities provided by
the software system and its operational constraints.
These requirements reflect the needs of the customer for a software system that helps solve the
problems of a customer.
The process of gathering, analyzing, documenting, and validating these system services/
functionalities and constraints is called Requirements Engineering.
It may range from a high-level abstract statement of a service or constraint to a detailed functional
specification.
The requirements may serve a dual function
▪ May be the basis for a bid for a contract - therefore must be open to interpretation;
▪ May be the basis for the contract itself - therefore must be defined in detail;
▪ Both these statements may be called requirements.
Requirements abstraction: Levels of Description

“If a company wishes to let a contract for a large software development project, it must define its
needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be
written so that several contractors can bid for the contract, offering, perhaps, different ways of
meeting the client organization’s needs. Once a contract has been awarded, the contractor must
write a system definition for the client in more detail so that the client understands and can validate
what the software will do. Both of these documents may be called the requirements document for
the system.”
❑ User requirements / User Stories
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 it may be part of a
contract between client and contractor.
❑ Software specification
A detailed software description which can serve as a basis for a design or implementation.
Written for developers.
Definitions and specifications – Example

❑ Requirement Definition
▪ The software must provide a means of representing and accessing external files created by
other tools.
❑ Requirement Specification

▪ The user should be provided with facilities to define and select the type of external files.
▪ Each external file type may have an associated tool which may be applied to the file.
▪ Each external file type may be represented as a specific icon on the user’s display area.
▪ When user selects an icon representing the external file, the associated tool is used to access
the file.
Characteristics of Good Requirements

1) Clear and unambiguous : Each requirement must have single interpretation. Since natural language is
prone to ambiguity, write requirements in simple, concise, straightforward language appropriate to
the user domain.
2) Correct: Each requirement must accurately describe the functionality to be built. Reviews are used to
ensure the correctness of requirements
3) Feasible: It must be possible to implement each requirement within the known capabilities and
limitations of the system and its operating environment. To avoid specifying unattainable
requirements.
4) Complete: Each requirement must fully describe the functionality to be delivered. It must contain all
the information necessary for the developer to design and implement that bit of functionality. No
requirements or necessary information should be absent. Missing requirements are hard to spot!
Focusing on user tasks, rather than on system functions, can help you to prevent incompleteness.
5) Necessary: Each requirement should document a capability that the stakeholders really need or one
that’s required for conformance to an external system requirement or a standard. Every requirement
should originate from a credible source that has the authority to specify requirements.

6) Prioritized: Assign an implementation priority to each functional requirement, feature, or user story
to indicate how essential it is to a particular product release. If all the requirements are considered
equally important, it’s hard for the project manager to respond to budget cuts, schedule overruns,
personnel losses, or new requirements added during development. Prioritization is an essential key
to successful iterative development.
7) Consistent: Consistent software requirements don’t conflict with other requirements of the same
type or with higher-level business, system, or user requirements.
8) Modifiable: You must be able to revise the requirements when necessary and maintain a history of
changes made to each requirement. This dictates that each requirement be uniquely labeled and
expressed separately from other requirements so that you can refer to it unambiguously.
9) Verifiable: You need to devise a few tests or use other verification approaches, such as inspection or
demonstration, to determine whether the software system properly implements each requirement.
If a requirement isn’t verifiable, determining whether it was correctly implemented becomes a
matter of opinion, not objective analysis. For example, a requirement stating that the system must
be user-friendly is not verifiable and listing such requirements should be avoided.
10) Traceable: A traceable requirement can be linked backwards to its origin and forward to the design
elements and source code that implement it and to the test cases that verify the implementation as
correct. Traceable requirements are uniquely labeled with persistent identifiers. They are written in a
structured, fine-grained way as opposed to crafting long narrative paragraphs. Avoid lumping
multiple requirements together into a single statement; the individual requirements might trace to
different design and code elements.
Requirements Classification
Software system requirements are mainly classified as
❑ Functional requirements
These are descriptions / statements of services or business functions the system should
provide.
❑ Non-functional requirements
There are constraints or restrictions or requirements imposed on the services or functions

offered by the system.
Functional requirements
Describe what the system should do in terms of business functions or system services.
These requirements depend on the type of software, expected users and the type of system where
the software is used.
These are in form of high-level statements of what the system should do.
Functional system requirements should describe the system services in detail.
❖ Example: Mentcare system (An organization that runs a chain of Clinics; Doctors, Nurses, Medical
Staff, Patients are users of the system): functional requirements:
1. A user shall be able to search the appointments lists for all clinics.

2. The system shall generate each day, for each clinic, a list of patients who are expected to
have appointments that day.
3. Each staff member using the system shall be uniquely identified by his or her 8-digit
employee number.
Non-functional requirements
These requirements define system properties or quality attributes such as security, reliability,
performance, maintainability, scalability, portability, and usability etc.
Sometimes, engineering process requirements may also require a particular IDE, programming
language or development method.
Sometimes, regulatory norm, and standards may also constitute non-functional requirements.
Non-functional requirements are difficult for the user / customer / stakeholders to express properly /
articulate.
Non-functional requirements may be more critical than functional requirements. If these are not
met, the system may be useless.
Non-functional requirements may affect the overall architecture of a system rather than the
individual components.
A single non-functional requirement, such as a security, privacy, regulatory requirement, may

generate a number of related functional requirements that define system services that are required.
Non-functional classifications
❑ Product requirements
Requirements which specify that the delivered product must behave in a particular way e.g.
usability, execution speed or performance, reliability / availability etc.
❑ Organisational requirements
Requirements which are a consequence of organisational policies and procedures e.g.

delivery requirements, standards requirements, implementation requirements, etc.
❑ External requirements
Requirements which arise from factors which are external to the system and its development
process e.g. interoperability requirements, privacy, safety requirements, etc.
❖ Examples of nonfunctional requirements in the Mentcare system
Product requirement
▪ The Mentcare system shall be available to all clinics during normal working hours (Mon–Fri,
08.30–17.30). Downtime within normal working hours shall not exceed five seconds in any
one day.
Organizational requirement
▪ Users of the Mentcare system shall authenticate themselves using their identity card.

External requirement
▪ The system shall implement patient privacy provisions as set out in Govt Privacy Act.
Metrics for specifying non-functional requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure

Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
Requirements Engineering Processes

The goal of requirements engineering (RE) process is to create and maintain a software
requirements document.
The overall process includes 4 high-level sub-processes:
Assessing whether the system is useful to the business (feasibility study).
Discovering requirements (elicitation and analysis).
Converting the requirements into some standard form (specification).
Checking that the requirements actually define the system that the customer wants
(validation).
Feasibility studies
A feasibility study decides whether or not the proposed system is worthwhile
A short focused study that checks
✓ If the system contributes to organisational objectives
✓ If the system can be engineered using current technology and within budget
✓ If the system can be integrated with other systems that are used
❑ Different Feasibilities are:

▪ Financial Feasibility
▪ Technological Feasibility
▪ Operational Feasibility
▪ Economical Feasibility
Requirements Elicitation and Analysis
Software engineers work with different stakeholders (may involve end-users, managers,
maintenance engineers, domain experts, unions leaders, etc. ) to find out about the application
domain, the services/ functions that the system should provide, the required system performance,
hardware constraints, other systems with which it may interface, etc.
❑ The requirements elicitation and analysis process :
Requirements discovery,
▪ Interacting with stakeholders to discover their requirements. Several techniques

include: interview, observation, reading and questionary.
Requirements classification and organization,
▪ Grouping related requirements and organising them into coherent clusters.
Requirements prioritization and negotiation,
▪ Prioritising requirements and resolving requirements conflicts.
Requirements specification.

▪ Requirements are documented and form input into the next stage of software
development.
Problems of requirements elicitation
1) Stakeholders don’t know what they really want.
2) Stakeholders express requirements in their own terms.
3) Different stakeholders may have conflicting requirements.
4) Organisational and political factors may influence the system requirements.
5) The requirements may change during the analysis process.
▪ New stakeholders may emerge and the business environment may change.
▪ Accommodating the requirements change may affect budget and delivery time.
Requirements specification
The process of writing down the user and system requirements in a requirements document.
User requirements have to be understandable by end-users and customers who do not have a
technical background.
System requirements are more detailed requirements and may include more technical information.
The requirements may be part of a contract for the system development
It is therefore important that these are as complete as possible.
Requirements specification can be written down using natural language, structured natural language,
graphical notations or a combination of these.
Requirements validation
It is concerned with demonstrating that the requirements define the system that the customer really
wants.
Requirements error costs are high, so validation is very important
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an
implementation error.
❑ 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?
▪ Feasibility. Can the requirements be implemented given available budget and technology
▪ Verifiability. Can the requirements be checked with the system when it is developed?
❑ Requirements validation techniques
▪ Requirements reviews

✓ Regular reviews should be held while the requirements definition is being

formulated.
✓ Both customer and development staff should be involved in reviews.
✓ Reviews may be formal (with completed documents) or informal. Good

communications between developers, customers and users can resolve problems at
an early stage.
▪ .Prototyping
✓ Using an executable model of the system to check requirements.
Requirements specification
It is the process of writing down the requirements of the user and system in a requirements
document following a standard practice.
User requirements have to be understandable by end-users and customers who do not have a
technical background.
System (or software) requirements are more detailed requirements and may include more technical
information.
The requirements may be part of a contract for the system development
It is therefore important that these are as complete as possible.
Example:
❑ User Requirement Definition
▪ The software must provide a means of representing and accessing external files created by
other tools.
❑ Software Requirement Specification
▪ The user should be provided with facilities to define and select the type of external files.
▪ Each external file type may have an associated tool which may be applied to the file.
▪ Each external file type may be represented as a specific icon on the user’s display area.
▪ When user selects an icon representing the external file, the associated tool is used to access
the file.
Ways of writing system requirements specification
Notation Description
Natural language The requirements are written using numbered sentences in natural language. Each
sentence should express one requirement.

Structured natural The requirements are written in natural language on a standard form or template.
language Each field provides information about an aspect of the requirement.
Design description This approach uses a language like a programming language, but with more
languages abstract features to specify the requirements by defining an operational model of
the system. This approach is now rarely used although it can be useful for
interface specifications.
Graphical notations Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and sequence diagrams are
commonly used.
Mathematical These notations are based on mathematical concepts such as finite-state

specifications machines or sets. Examples: Petri Nets, and Z. Although these unambiguous
specifications can reduce the ambiguity in a requirements document, most
customers don’t understand a formal specification. They cannot check that it
represents what they want and are reluctant to accept it as a system contract
Natural language specification

Requirements are written as natural language sentences supplemented by diagrams and tables if
any.
Used for writing requirements because it is expressive, intuitive and universal. This means that the
requirements can be understood by users and customers.
❑ Guidelines for writing requirements
▪ Develop a standard format and use it for all requirements.
▪ Use language in a consistent way. Use shall for mandatory requirements, should for desirable
requirements.
▪ Use text highlighting to identify key parts of the requirement.
▪ Avoid the use of computer jargon.
▪ Include an explanation (rationale) of why a requirement is necessary.
❑ Problems with natural language
▪ Lack of clarity
▪ Precision is difficult to achieve, hence making the document difficult to read and
interpret.
▪ Requirements confusion
▪ Functional and non-functional requirements tend to be mixed-up.
▪ Requirements amalgamation

▪ Several different requirements may be expressed together.
Requirements Specification: an Example of a Simple Library Management System

▪ R1. The library system shall have different users such as librarian, students, faculty and staff of
the college.
▪ R2. Each user of the system shall be authenticated by the system.
▪ R3. There shall be role based access to the system (for example a student member cannot access
the system to issue or return books for him, librarian can do such work).
▪ R4. The system shall allow new members to the library and their maintenance like edit member
information and delete a member from the library.
▪ R5. The system shall add new books when they are procured for the library.
▪ R6. The system shall perform issue and return of books to members. Any member cannot be
issued more than 3 books at any time.
▪ R7. The system shall calculate fines (Rs.1 per day) if a book retained by a user for more than two
weeks.
▪ R8. The system shall have a search facility which enables library users to find a book easily using
book title.
▪ R9. A user can place a reserve request for a book if it is presently not available for issue. The
request should be fulfilled on first-come-first-serve basis when the book is available in the library.
▪ R10. The system shall generate several periodic reports such as volume of transactions per day,
per week, books which are retained for many days, users who access library most frequently etc.
Structured specifications
A limited form of natural language may be used to express requirements.
This removes some of the problems resulting from ambiguity and flexibility and imposes a degree of
uniformity on a specification.
Often supported by use of a forms-based approach
❑ Form-Based Specification
▪ Definition of the function
▪ Description of inputs and where they come from
▪ Description of outputs and where they go to
▪ Indication of other entities required
▪ Pre and post conditions (if appropriate)
▪ Other descriptions (if any)
Structured specifications: Example - Simple Library Management System

▪ Function: Search Book

▪ Description: This function of the system will allow a library user to search a book using title of the
book, and/or author name.
▪ Inputs: book title, author name, or both
▪ Outputs: The system will display a list of available books matching the title, and/or author. If no such
book is available, the system will display a message “No matching book is available”.
▪ Pre-condition: The library user should select the search book option provided in the system menu to
initiate search book function.
▪ Post-condition: The search results remain visible on the screen. If several books are listed, then the
screen should be scrollable.
Graphical Notation
Use-cases that are part of the UML (Unified Modelling Language) may be used.
An use case identifies a system functionality and the actor (user) who interacts with it.
A set of use cases should describe all possible interactions with the system.
A use-case diagram that contains a set of use cases that shows the system functionalities and
different users who interact with those functionalities.
High-level graphical model supplemented by more detailed tabular description (e.g., use case
specifications).
UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event
processing in the system.
Example: Simple Library Management System

Figure: UseCase diagram
Use Case Specification

Use Case Name: Login
Actors: Librarian, Student, Any other Library User
Description: A registered user can login to the system and once authenticated, can initiate subsequent
actions.
Flow of Events
A. Basic Flow
1) The registered user chooses to Login.
2) The system prompts for username and password.
3) The registered user submits username and password.
4) The system verifies the username and password combination. It authorizes the registered user
according to the role(s) to which the user has been assigned. Then it displays the main interface and
awaits subsequent action from the user.
B. Alternative Flows
1) Invalid Username/Password: The system displays the Authentication Failed message.

2) Account Locked: The system displays the “Unauthorized User, System Locked” message and does not
permit any further attempts to login after 3 failed attempts.
Special Requirements : Minimum password length is 8 characters, and must include a combination of
characters including at least one non-alphabetic character.
Pre-conditions
1. User must have registered.
Post-conditions
1. Login Success: The system displays the main interface from which additional actions can be initiated
by the user.
2. Login Failure: If the Login fails as described in any of the alternative flows above, an appropriate
message is displayed and the user is not considered authenticated.
SRS Document
The SRS (software requirements specification) document is the official statement of what the system
developers should implement in software system.
It includes both the user requirements for a software system and a detailed specification of the
system requirements.
In some cases, the user requirements, and the system requirements may be integrated into a single
description.
Should include both a definition and a specification of 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.
IEEE requirements standard

This is a generic structure that must be instantiated for specific systems
1. Introduction
1.1 Purpose of the requirement document
1.2 Scope of the product
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview of the remainder of the document
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics

2.4 General constraints
2.5 Assumptions and dependencies
3. Specific requirements
This section is the most substantial part of the document and covers functional, non-functional and
external interface requirements. The structure of this section varies from organizations to organization.
4. Appendices
5. Index
Suggested SRS Document Structure

1. Preface: This should define the expected readership of the document and describe its version
history, and a summary of the made in each version.
2. Introduction: This should describe the need for the system. It should briefly describe its functions
and explain how it will work with other systems. It should describe how the system fits into the
overall business or strategic objectives of the organization.
3. Glossary: This should explain the technical terms used in the document.
4. User requirements definition: This section provides the user requirements describes in natural
language, diagrams or other notations that are understandable to the customers. Product and
process standards which must be followed should be specified.
5. System architecture: This section should present a high-level description of the system showing the
distribution of functions across system modules. Architectural components that are reused should be
highlighted.
6. System requirements specification: This should describe the functional and non-functional
requirements in more detail.
7. System models: This section should contain one or more system models characterising the system,
its components, and its environment. These might be behavioural models, structural models and
data models
8. System evolution: This should describe the anticipated changes due to hardware evolution, changing
user and business needs, etc.
9. Appendices: This section should provide additional detail information related to item provided in the
above sections.
10. Index: An alphabetic index to the document may be included.
Requirements Modelling Approaches

Structured Analysis
One view of requirements modeling, called structured analysis, considers data and the
processes that transform the data as separate entities.
Data Modeling: Data objects are modeled in a way that defines their attributes and
relationships. (e.g. E-R Model)

Process Modeling: Processes that manipulate data objects are modeled in a manner that
shows how they transform data as data objects flow through the system. (e.g. Data Flow
Diagram)
Object-Oriented Analysis
A second approach to analysis modeling, called object-oriented analysis, focuses on the

definition of classes and the manner in which they collaborate with one another to effect
software requirements.
UML (Unified Modeling Language) models are predominantly object oriented.
The Unified Modeling Language (UML)

The UML is a general-purpose standard visual modeling language in software engineering used to
specify, visualize, construct, and document software system.
The UML has been standardized by Object Management Group (OMG) in 1997 and periodically revise
it. The current version is UML 2.5.1 released in 2017.
UML specification defines two major kinds of UML diagram: structure diagrams and behavior
diagrams.
Structure diagrams show the static structure of the system and its parts on different abstraction and
implementation levels and how they are related to each other. The elements in a structure diagram
represent the meaningful concepts of a system, and may include abstract, real world and
implementation concepts.
Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as
a series of changes to the system over time.
4+1 View of the System

• Use
case View: Use case diagrams are used to view a system as a set of discrete activities or functions.
• Process View: The dynamic behavior of a system can be seen using the process view. The different
diagrams such as the state chart diagram, activity diagram, sequence diagram, and collaboration
diagram are used in this view.
• Design View: The design view of a system is the structural view of the system. This gives an idea of
what a given system is made up of. Class diagrams and object diagrams form the design view of the
system.
• Component View: The component view shows the grouped modules of a given system modeled
using the component diagram.
• Deployment View: The deployment diagram of UML is used to identify the deployment modules for
a given system.
UML Tools: Visual Paradigm, Enterprise Architect, Star UML, Lucid Chart, Magic Draw, Visio, Creately
Building Requirements Analysis Models

Requirements analysis results in the specification of software’s operational characteristics, indicates

software’s interface with other system elements, and establishes constraints that software must
meet.
Requirements analysis allows a software engineer to elaborate on basic requirements established

during requirements engineering process.
Elements of the analysis model
Scenario-based Models
Provide processing narratives for software functions
Use-case Model, Activity Diagram
Class-based Models
Represent object-oriented classes and the manner in which classes collaborate to

achieve system requirements.
Behavioral Models
Depict how the software behaves as a consequence of external events.
State diagram, Sequence diagram
Flow-oriented Models
Data flow diagram

Data Models that depict the information domain for the system: E-R diagram
These models provide a software designer with information that can be translated to architectural
design, interface designs, and component-level designs.
Use Case Diagram
❖ A use-case model describes a system's functional requirements in terms of use cases. It is a model of
the system's intended functionality (use cases) and external users in its environment (actors).
❖ UseCase Model has two parts:
▪ UseCase Diagram (Graphical Part, optional)
▪ UseCase Specification (Textual Part, mandatory)
❖ Each UseCase in a UseCase diagram represents one and only one functionality.

❖ An UseCase describes an interaction between a user (called an Actor) and the functionality provided
by the system.
❖ It models the interaction as a dialogue between an actor and the system
❖ Actor is an external entity that interacts with the system.
❖ A boundary is the dividing line between the system and its environment.
❖ Use cases are within the boundary.
❖ Actors are outside of the boundary.
See the Library Case Study for details
Reuse in Use Case
Reuse in uses case model is achieved through include and exclude use cases.
Include: Include is a directed relationship between two use cases, which implies that the behavior of
the included use case is inserted into the behavior of the including use case. It is a Mandatory
Relation.
Extend (or Exclude): Extend is a relationship between two use cases, which specifies how and when
the extended use case insert the behavior defined in the extending use case. (Normally Exceptions)

The extend relationship adds new incremental behavior to a use case. Specialized use case extends
the general use case. It is an Optional Relation.
Generalization and Specialization
•
Direct access to the generalized use case is avoided and replaced with direct access to its specializing
use
• When a use case is associated with more than one actor, the overlapping roles between the two
actors should be generalized into a separate actor.
• In library case study,:
• Library Member: Student, Faculty, Staff
Activity Diagram

It supplements the use case by providing a graphical representation of the flow of interaction within
a specific scenario.
It is like flow chart, but more formal and expressive (due to model elements).
Activity Diagrams
▪ model activities in one use cases
▪ model complex workflows in operations on objects
▪ show how a collection of use cases coordinate to create a workflow for an organisation/
system
Elements of Activity Diagram























*** End ***

SE Module 2 and 3

Uploaded by

Copyright:

Available Formats

SE Module 2 and 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE Module 2 and 3

Uploaded by

Copyright:

Available Formats

Software Engineering (22BCA3C01)

3rd Semester, Dept. of BCA 1

What are Software Requirements?

The requirements may serve a dual function

▪ Both these statements may be called requirements.

Requirements abstraction: Levels of Description

❑ User requirements / User Stories

Definitions and specifications – Example

3rd Semester, Dept. of BCA 2

Characteristics of Good Requirements

3rd Semester, Dept. of BCA 3

There are constraints or restrictions or requirements imposed on the services or functions

Functional system requirements should describe the system services in detail.

3rd Semester, Dept. of BCA 4

A single non-functional requirement, such as a security, privacy, regulatory requirement, may

Requirements which are a consequence of organisational policies and procedures e.g.

❖ Examples of nonfunctional requirements in the Mentcare system

3rd Semester, Dept. of BCA 5

Metrics for specifying non-functional requirements

Speed Processed transactions/second

User/event response time

Screen refresh time

Ease of use Training time

Number of help frames

Reliability Mean time to failure

Rate of failure occurrence

Robustness Time to restart after failure

Percentage of events causing failure

3rd Semester, Dept. of BCA 6

Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems

Requirements Engineering Processes

The overall process includes 4 high-level sub-processes:

Assessing whether the system is useful to the business (feasibility study).

Discovering requirements (elicitation and analysis).

Converting the requirements into some standard form (specification).

A feasibility study decides whether or not the proposed system is worthwhile

A short focused study that checks

✓ If the system contributes to organisational objectives

❑ Different Feasibilities are:

3rd Semester, Dept. of BCA 7

Requirements Elicitation and Analysis

❑ The requirements elicitation and analysis process :

▪ Interacting with stakeholders to discover their requirements. Several techniques

Requirements classification and organization,

▪ Grouping related requirements and organising them into coherent clusters.

Requirements prioritization and negotiation,

▪ Prioritising requirements and resolving requirements conflicts.

3rd Semester, Dept. of BCA 8

Problems of requirements elicitation

1) Stakeholders don’t know what they really want.

2) Stakeholders express requirements in their own terms.

3) Different stakeholders may have conflicting requirements.

4) Organisational and political factors may influence the system requirements.

5) The requirements may change during the analysis process.

The requirements may be part of a contract for the system development

It is therefore important that these are as complete as possible.

Requirements error costs are high, so validation is very important