• Requirements are refined

• Prototype is turned to satisfy the needs of customer

LIMITATIONS OF PROTOTYPING
• In a rush to get it working, overall software quality or long term maintainability are generally
overlooked
• Use of inappropriate OS or PL
• Use of inefficient algorithm

THE SPIRAL MODEL

An evolutionary model which combines the best feature of the classical life cycle and
the iterative nature of prototype model. Include new element : Risk element. Starts in middle and
continually visits the basic tasks of communication, planning, modeling, construction and deployment

THE SPIRAL MODEL

• Realistic approach to the development of large scale system and software
• Software evolves as process progresses
• Better understanding between developer and customer
• The first circuit might result in the development of a product specification

Software Engineering Page 15

 • Subsequent circuits develop a prototype
• And sophisticated version of software

THE CONCURRENT DEVELOPMENT MODEL

• Also called concurrent engineering

• Constitutes a series of framework activities, software engineering action, tasks and their associated
states
• All activities exist concurrently but reside in different states
• Applicable to all types of software development
• Event generated at one point in the process trigger transitions among the states

A FINAL COMMENT ON EVOLUTIONARY PROCESS

• Difficult in project planning
• Speed of evolution is not known
Does not focus on flexibility and extensibility (more emphasis on high quality)
• Requirement is balance between high quality and flexibility and extensibility

THE UNIFIED PROCESS

Evolved by Rumbaugh, Booch, Jacobson. Combines the best features their OO models. Adopts
additional features proposed by other experts. Resulted in Unified Modeling Language (UML). Unified
process developed Rumbaugh and Booch. A framework for Object-Oriented Software
Engineering using UML

PHASES OF UNIFIED PROCESS

• INCEPTION PHASE
• ELABORATION PHASE
• CONSTRUCTION PHASE
• TRANSITION PHASE

The Unified Process (UP)

Software Engineering Page 16

 UNIFIED PROCESS WORK PRODUCTS
Tasks which are required to be completed during different phases
1. Inception Phase
*Vision document
*Initial Use-Case model
*Initial Risk assessment
*Project Plan

2. Elaboration Phase
*Use-Case model
*Analysis model
*Software Architecture description
*Preliminary design model
*Preliminary model

3. Construction Phase
*Design model
*System components
*Test plan and procedure
*Test cases
*Manual

4. Transition Phase
*Delivered software increment
*Beta test results
*General user feedback

Agility and Agile Process model

The meaning of Agile is swift or versatile."Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations, or parts
do not directly involve long term planning. The project scope and requirements are laid down at the
beginning of the development process. Plans regarding the number of iterations, the duration and the
scope of each iteration are clearly defined in advance

Software Engineering Page 17

 Phases of Agile model:
1. Requirements gathering
[Link] the requirements
[Link]/ iteration
[Link]/ Quality assurance
[Link]
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You should
explain business opportunities and plan the time and effort needed to build the project.
Based on this information, you can evaluate technical and economic feasibility.

2. Design the requirements: When you have identified the project, work with stakeholders to
define requirements. You can use the user flow diagram or the high-level UML diagram to
show the work of new features and show how it will apply to your existing system.

3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a working
product. The product will undergo various stages of improvement, so it includes simple,
minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's performance and
looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team receives
feedback about the product and works through the feedback.
Advantages:

1. Frequent Delivery
2. Face-to-Face Communication with clients.
[Link] design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.

Disadvantages:

1. Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.

Software Engineering Page 18

 2. Due to the lack of proper documentation, once the project completes and the developers
allotted to another project, maintenance of the finished project can become a difficulty.

Extreme Programming
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop
software.
Extreme Programming (XP) was conceived and developed to address the specific needs of
software development by small teams in the face of vague and changing requirements.
Extreme Programming is one of the Agile software development methodologies. It provides
values and principles to guide the team behavior. The team is expected to self-organize.
Extreme Programming provides specific core practices where −
 Each practice is simple and self-complete.

 Combination of practices produces more complex and emergent behaviour.

Other process models of Agile Development and Tools

 Crystal
 Scrum
Scrum
Scrum is aimed at sustaining strong collaboration between people working on complex
products, and details are being changed or added. It is based upon the systematic interactions
between the three major roles: Scrum Master, Product Owner, and the Team.

Software Engineering Page 19

  Scrum Master is a central figure within a project. His principal responsibility is to
eliminate all the obstacles that might prevent the team from working efficiently. 
 Product Owner, usually a customer or other stakeholder, is actively involved throughout
the project, conveying the global vision of the product and providing timely feedback on the
job done after every sprint.
 Scrum Team is a cross-functional and self-organizing group of people that is responsible
for the product implementation. It should consist of up to 7 team members, in order to stay
flexible and productive.

Crystal
Crystal is an agile methodology for software development. It places focus on people over
processes, to empower teams to find their own solutions for each project rather than being
constricted with rigid methodologies.
Crystal methods focus on:-
People involved
Interaction between the teams
Community
Skills of people involved
Their Talents
Communication between all the teams

Software Engineering Page 20

 MALLA REDDY COLLEGE OF ENGINEERING & TECHNOLOGY
DEPARTMENTOF COMPUTER SCIENCE AND ENGINEERING

UNIT II
SOFTWARE REQUIREMENTS

IEEE defines Requirement as :

1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or a system component to
satisfy constract, standard, specification or formally imposed document
3. A documented representation of a condition nor capability as in 1 or 2

SOFTWARE REQUIREMENTS
• Encompasses both the User’s view of the requirements( the external view ) and the Developer’s
view( inside characteristics)
User’s Requirements
--Statements in a natural language plus diagram, describing the services the system is expected to
provide and the constraints
• System Requirements --Describe the system’s function, services and operational condition

SOFTWARE REQUIREMENTS
• System Functional Requirements
--Statement of services the system should provide
--Describe the behavior in particular situations
--Defines the system reaction to particular inputs
• Nonfunctional Requirements
- Constraints on the services or functions offered by the system
--Include timing constraints, constraints on the development process and standards
--Apply to system as a whole
• Domain Requirements
--Requirements relate to specific application of the system
--Reflect characteristics and constraints of that system

FUNCTIONAL REQUIREMENTS
• Should be both complete and consistent
• Completeness
-- All services required by the user should be defined
• Consistent
-- Requirements should not have contradictory definition
• Difficult to achieve completeness and consistency for large system

NON-FUNCTIONALREQUIREMENTS
Types of Non-functional Requirements [Link] Requirements
-Specify product behavior
-Include the following

Software Engineering Page 21

 • Usability
• Efficiency
• Reliability
• Portability
2. Organizational Requirements
--Derived from policies and procedures
--Include the following:
• Delivery
• Implementation
• Standard
3. External Requirements
-- Derived from factors external to the system and its development process
--Includes the following
• Interoperability
• Ethical
• Legislative
PROBLEMS FACED USING THE NATURAL LANGUAGE
1. Lack of clarity-- Leads to misunderstanding because of ambiguity of natural language
2. Confusion-- Due to over flexibility, sometime difficult to find whether requirements are same or
distinct.
3. Amalgamation problem-- Difficult to modularize natural language requirements

STRUCTURED LANGUAGESPECIFICATION
• Requirements are written in a standard way
• Ensures degree of uniformity
• Provide templates to specify system requirements
• Include control constructs and graphical highlighting to partition the specification

SYSTEM REQUIREMENTS STANDARD FORM

• Function
• Description
• Inputs
• Source
• Outputs
• Destination
• Action
• Precondition
• Post condition
• Side effects

Interface Specification
• Working of new system must match with the existing system
• Interface provides this capability and precisely specified

Three types of interfaces

1. Procedural interface-- Used for calling the existing programs by the new programs [Link] structures-
-Provide data passing from one sub-system to another [Link] of Data
-- Ordering of bits to match with the existing system
--Most common in real-time and embedded system

Software Engineering Page 22

 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

The Software Requirements document

Suggests that there are 6 requirements that requirement document should satisfy. It should
• specify only external system behavior
• Specify constraints on the implementation.
• Be easy to change
• Serve as reference tool for system maintainers
• Record forethought about the life cycle of the system.
• Characterize acceptable responses to undesired events

Purpose of SRS
• Communication between the Customer, Analyst, system developers, maintainers,
• firm foundation for the design phase
• support system testing activities
• Support project management and control
• controlling the evolution of the system

IEEE requirements standard

Defines a generic structure for a requirements document that must be instantiated for each specific
system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.

IEEE requirements standard [Link]

Purpose
Scope
Definitions, Acronyms and Abbreviations
References
Overview
2. General description
Product perspective
Product function summary
User characteristics
General constraints
Assumptions and dependencies
3. Specific Requirements
- Functional requirements

Software Engineering Page 23

 -External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability, maintainability, transferability/conversion
- Other requirements
• Appendices
• Index
REQUIREMENTS ENGINEERING PROCESS
To create and maintain a system requirement document. The overall process includes four high level
requirements engineering sub-processes:
1. Feasibility study
--Concerned with assessing whether the system is useful to the business [Link] and analysis
--Discovering requirements [Link]
--Converting the requirements into a standard form [Link]
-- Checking that the requirements actually define the system that the customer wants

SPIRAL REPRESENTATION OF REQUIREMENTSENGINEERING PROCESS

Process represented as three stage activity. Activities are organized as an iterative process around a
spiral. Early in the process, most effort will be spent on understanding high-level business and the use
requirement. Later in the outer rings, more effort will be devoted to system requirements engineering
and system modeling
Three level process consists of: [Link] elicitation
2. Requirements specification
3. Requirements validation

Software Engineering Page 24

 FEASIBILITY STUDIES
Starting point of the requirements engineering process
• Input: Set of preliminary business requirements, an outline description of the system and how the
system is intended to support business processes
• Output: Feasibility report that recommends whether or not it is worth carrying out further Feasibility
report answers a number of questions:
1. Does the system contribute to the overall objective
2. Can the system be implemented using the current technology and within given cost and schedule
3. Can the system be integrated with other system which are already in place.

REQUIREMENTS ELICITATION ANALYSIS

Involves a number of people in an organization.

Stakeholder definition-- Refers to any person or group who will be affected by the system directly or
indirectly i.e. End-users, Engineers, business managers, domain experts.

Reasons why eliciting is difficult

1. Stakeholder often don’t know what they want from the computer system. 2. Stakeholder expression of
requirements in natural language is sometimes difficult toUnderstand.
3. Different stakeholders express requirements differently
4. Influences of political factors Change in requirements due to dynamic environments.

REQUIREMENTS ELICITATION PROCESS

Process activities
1. Requirement Discovery -- Interaction with stakeholder to collect their requirements including
domain and documentation
2. Requirements classification and organization -- Coherent clustering of requirements from
unstructured collection of requirements
3. Requirements prioritization and negotiation -- Assigning priority to requirements
--Resolves conflicting requirements through negotiation
4. Requirements documentation -- Requirements be documented and placed in the next round of spiral

Software Engineering Page 25

 The spiral representation of Requirements Engineering

REQUIEMENTS DICOVERY TECHNIQUES

1. View points --Based on the viewpoints expressed by the stake holder

--Recognizes multiple perspectives and provides a framework for discovering conflicts in the
requirements proposed by different stakeholders
Three Generic types of viewpoints
1. Interactor viewpoint--Represents people or other system that interact directly with the system
2. Indirect viewpoint--Stakeholders who influence the requirements, but don’t use the system
[Link] viewpoint--Requirements domain characteristics and constraints that influence the
requirements.

2. Interviewing--Puts questions to stakeholders about the system that they use and the system to be
developed. Requirements are derived from the answers.
Two types of interview
– Closed interviews where the stakeholders answer a pre-defined set of questions.
– Open interviews discuss a range of issues with the stakeholders for better understanding their needs.

Software Engineering Page 26