Unit-II [14 M]

Software Requirement Engineering

- Software engineering practice
- Core Principles of software
- Communication practices
- Planning practices
- Modeling practices
-Analysis modeling practices
- Design modeling practices
- Construction practices
- Coding
- Testing
- Deployment practices
-Requirement Engineering (RE)
-Software Requirement Specification (SRS)
 Software Engineering Practice
• Consists of a collection of concepts, principles, methods, and tools
that a software engineer calls upon on a daily basis
• Equips managers to manage software projects and software engineers
to build computer programs
• Provides necessary technical and management how to’s in getting the
job done
• Transforms a haphazard unfocused approach into something that is
more organized, more effective, and more likely to achieve success

2
 The Essence of Practice
1) Understand the problem (communication and analysis)
• Who has a stake in the solution to the problem?
• What are the unknowns (data, function, behavior)?
• Can the problem be compartmentalized?
• Can the problem be represented graphically?
2) Plan a solution (planning, modeling and software design)
• Have you seen similar problems like this before?
• Has a similar problem been solved and is the solution reusable?
• Can subproblems be defined and are solutions available for the
subproblems?

(more on next slide)

3
 The Essence of Problem Solving
(continued)
3) Carry out the plan (construction; code generation)
• Does the solution conform to the plan? Is the source code traceable
back to the design?
• Is each component of the solution correct? Has the design and code
been reviewed?
4) Examine the results for accuracy (testing and quality assurance)
• Is it possible to test each component of the solution?
• Does the solution produce results that conform to the data, function,
and behavior that are required?

4
 Seven Core Principles for Software
Engineering
1) The reason at all exists
• The software should provide value to its users and satisfy the requirements
2) Keep it simple, stupid (KISS)
• All design and implementation should be as simple as possible
3) Maintain the vision
• A clear vision is essential to the project’s success
4) What you produce, others will consume
• Always specify, design, and implement knowing that someone else will later
have to understand and modify what you did
5) Be open to the future
• Never design yourself into a corner; build software that can be easily changed
and adapted
6) Plan ahead for reuse
• Reuse of software reduces the long-term cost and increases the value of the
program and the reusable components
7) Think
• Placing clear, complete thought before action will almost always produce better
results
5
 Communication Practices
(Requirement Gathering)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
6
 Communication Principles
1. Listen
Listen to the speaker and concentrate on what is being said
2. Prepare before you communicate
Prepare before you meet by researching and understanding the problem
3. Someone should facilitate the activity
Communication should have the facilitator to keep conversation
moving in the productive direction
4. Face-to-face communication is best
But also have a document or presentation to focus the discussion
5. Take notes and document decisions
Write down all important points & issues raised in the meeting
6. Strive for collaboration
Each small collaboration serves to build trust among team members
7. Stay focused; modularize your discussion
Limited peoples should involved in the meeting while discussing

7
 (continued)
8. If something is unclear, draw a picture
When verbal communication becomes difficult, sketch or drawing
can help in giving clarity
9. a) Once you agree to something, move on
b) If you cannot agree to something, move on
c) If a feature or function is unclear and cannot be clarified at the
moment, move on
In the meeting many people will discuss different issues, need to
know moving on is sometimes the best way to accomplish communication.
10. Negotiation is not a contest or a game; it works best when both
parties win
If there is negotiation then parties have same goal & they work
towards it

8
 Planning Practices
(Defining a Road Map)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
9
 Planning Principles
1. Understand the scope of the project
Software planning provides the exact goal for software development team
2. Involve the customer in the planning activity
Customer’s participation can clearly state their priorities, delivery date,
project increments, budget, etc.
3. Recognize that planning is iterative
A project plan is always changing. The planning can be changed according
to feedback from customer
4. Estimate based only on what you know
The team can work efficiently if efforts, task & cost estimation is reliable
5. Consider risk as you define the plan
The project plan should be adjusted to accommodate the likelihood that
one or more risks will occur.
6. Be realistic
The project plan must be realistic. The plan may lag due to some technical
reason or may be due to personal reason of the team.

10
7. Adjust granularity as you define the plan
Granularity means level of detail for particular specification. In general
granularity moves from high to low . The greater the granularity, the deeper the
level of detail.
8. Define how you intend to ensure quality
The plan should identify how the software team intends to ensure quality.
If technical reviews are to be conducted, they should be scheduled.
9. Describe how you intend to accommodate change
The plan should identify how changes are to be accommodated as
software engineering work proceeds.
10.Track the plan frequently and make adjustments as required
Track project progress on daily basis, looking for problem areas &
situations.

11
 Barry Boehm’s W HH
5 Principle
• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible for each function?
• Where are they organizationally located?
• How will the job be done technically and managerially?
• How much of each resource is needed?

12
 Modeling Practices
(Analysis and Design)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
13
 Analysis Modeling Principles
1. The information domain of a problem must be represented and understood
The data that flows into the system, the data that flow out of a system & the
data stores that collect & organize persistent data objects

2.The functions that the software performs must be defined

Functions are processes those transform the input flow to the output flow.
3. The behavior of the software (as a consequence of external events) must be
represented
The behavior of the system shows how the system makes transition from one
state to another on the occurrence of some external event.
4. The models that depict information, function, and behavior must be partitioned
in a manner that uncovers detail in a layered (or hierarchical) fashion
Use divide & conquer strategy. A large problem is divided into subproblems
until each problem is relatively easy to understand. This concept is called as partitioning
5. The analysis task should move from essential information toward
implementation detail
The analysis model is converted into design model in the next step. Hence
requirement analysis should be clear enough. 14
 Design Modeling Principles
1. The design should be traceable to the analysis model
Using elements of analysis model, design model is constructed
2. Always consider the software architecture of the system to be built
Software architecture is the skeleton of the system to be built. For this
reasons, design should start with architectural considerations.
3. Design of data is as important as design of processing functions
Data design is an essential element of architectural design. A well
structured data design helps to simplify maximum problems during
implementation.
4. Interfaces (both internal and external) must be designed with care
A well designed interface makes integration easier & assists the tester
in validating component functions.
5. User interface design should be tuned to the needs of the end-user.
However, in every case, it should stress ease of use
The design must be as per convenience of the end user of the system

15
6. Component-level design should be functionally independent (high
cohesion)
The functionality that is delivered by the component or module
should be cohesive( closely related)
7. Components should be loosely coupled to one another and to the
external environment
For good design, the coupling among different components should
be minimum i.e. component coupling should be kept as low as is reasonable.
8. Design representations (models) should be easily understandable
The purpose of design is to communicate information to all other
practitioners those will working on it. Hence design should be as simple as
possible.
9. The design should be developed iteratively; with each iteration, the
designer should strive for greater simplicity
Customer may suggest modifications after each delivery of the
increment. Good design should be capable to accommodate the changes as
per the requirement.

16
 Construction Practices

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
17
 Coding Principles
Preparation Principles: Before you write one line of code, be sure you
1) Understand the problem you are trying to solve
2) Understand basic design principles and concepts
3) Pick a programming language that meets the needs of the software to
be built and the environment in which it will operate
4) Select a programming environment that provides tools that will make
your work easier
5) Create a set of unit tests that will be applied once the component you
code is completed

18
 Coding Principles
Programming Principles: As you begin writing code, be sure you
1) Constrain your algorithms by following structured programming
practices
2) Select data structures that will meet the needs of the design
3) Understand the software architecture and create interfaces that are
consistent with it
4) Keep conditional logic as simple as possible
5) Create nested loops in a way that makes them easily testable
6) Select meaningful variable names and follow other local coding
standards
7) Write code that is self-documenting
8) Create a visual layout (e.g., indentation and blank lines) that aids
code understanding

19
 Coding Principles

Validation Principles: After you have completed your the first coding
pass, be sure you
1) Conduct a code walkthrough
2) Perform unit tests (black-box and white-box) and correct errors you
have uncovered
3) Refactor the code

20
 Testing Objectives
• Testing is a process of executing a program with
the intent of finding an error.
• A good test case is one that has a high probability
of finding an as-yet- undiscovered error.
• A successful test is one that uncovers an as-yet-
undiscovered error.

21
 Testing Principles
1. All tests should be traceable to the customer requirements:
The aim of testing is to find defect & defects are considered from
customer’s point of view
2. Tests should be planned long before testing begins
Testing plan can be started as soon as analysis model is completed. Mostly
all tests can be planned before starting actual coding.
3. The Pareto principle applies to software testing
80% of the uncovered errors will likely be traceable to 20% of the code
4. Testing should begin “in the small” and progress toward testing “in the
large”
Testing should start from individual units and finally go towards testing of complete
system as ‘whole’
Unit testing --> integration testing --> validation testing --> system testing
5. Exhaustive testing is not possible
It is impossible to execute every combination of paths during testing.

22
 Deployment Practices

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
23
 Deployment Principles
1. Customer expectations for the software must be managed
Be careful not to promise too much or to mislead the user
2. A complete delivery package should be assembled and tested
A CD ROM or other media containing all executable software,
support files other relevant information should be assembled tested with
actual users.
3. A support regime must be established before the software is delivered
Support should be planned, support material should be prepared &
appropriate mechanism should be established.
4. Appropriate instructional materials must be provided to end users
Actual project delivery includes all documentations, help files &
guidelines for handling the software by user.
5. Buggy software should be fixed first, delivered later
Don’t deliver any defective software to the customer

24

 Requirements Engineering
- Problems with requirements practices
- Requirements engineering tasks
- Inception
- Elicitation
- Elaboration
- Negotiation
- Specification
- Validation
- Requirements management 25
The Problems with our Requirements Practices

• We have trouble understanding the requirements that

we do acquire from the customer
• We often record requirements in a disorganized manner
• We spend far too little time verifying what we do
record
• We allow change to control us, rather than establishing
mechanisms to control change
• Most importantly, we fail to establish a solid
foundation for the system or software that the user
wants built
26
• Requirement Engineering:-
Software process perspective, requirements engineering
is a major software engineering action that begins
during the communication activity and continues into
the modeling activity. It must be adapted to the needs of
the process, the project, the product, and the people
doing the work.
• Need of Requirement Engineering:-
Requirements engineering tools assist in requirements
gathering, requirements modeling, requirements
management, and requirements validation.

27
 Requirements Engineering Tasks
• Seven distinct tasks
– Inception
– Elicitation
– Elaboration
– Negotiation
– Specification
– Validation
– Requirements Management
• Some of these tasks may occur in parallel and all are
adapted to the needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design
and construction of the software 28
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

29
 Inception Task
Inception means beginning. It is always
problematic to the developer that from where to
start. The customer and developer meet and they
decide overall scope and nature of the problem.
The aim is
a. To have the basic understanding of problem
b. To know the people who will use the software
c. To know exact nature of problem

30
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

31
 Elicitation Task
• Elicitation means to draw out the truth or reply from
anybody. In relation with requirement engineering,
elicitation is a task that helps the customer to define
what is required.
Following are some problem occur while deciding fixed set of
requirements
Problem of Scope: Unnecessary details state by the customer may
confuse developer instead of giving clarity of overall system objectives.
Problems of understanding: Sometimes both customer as well as
developer has poor understanding of what is needed, capabilities &
limitations of the computing environment, etc.
Problems of volatility: Volatility means change from one state to
another state. The customer’s requirements may change time to time.32
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

33
 Elaboration Task
• Elaboration means ‘ to work out in detail’.
– During elaboration, the software engineer takes
the information obtained during inception and
elicitation and begins to expand and refine it
– Elaboration focuses on developing a refined
technical model of software that will include
functions, features, and constraints

34
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

35
 Negotiation Task
• Negotiation means ‘discussion on financial &
other commercial issues’.
– This phase will involve the negotiation
between what user actual expects from the
system and what is actual feasible for the
developer to build.
– But based on the other aspect and feasibility
of a system the customer and developer can
negotiate on the few key aspect of the system

36
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

37
 Specification Task
• The specification is the final work product produced
by the requirement engineers.
• It serves as the foundation for subsequent software
engineering activities.
• It describes the function and performance of a
computer-based system and the constraints that will
govern its development
• It formalizes the informational, functional, and
behavioral requirements of the proposed software in
both a graphical and textual format
38
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

39
 Validation Task
During validation, the work products produced as a
result of requirements engineering are assessed for
quality
The specification is examined to ensure that
– all software requirements have been stated
unambiguously
– inconsistencies, omissions, and errors have been
detected and corrected
– the work products conform to the standards
established for the process, the project, and the product

40
Inception

Elicitation

Elaboration

Negotiation

Specification

Validation

Requirements
Management

41
 Requirements Management Task
• During requirements management, the project
team performs a set of activities to identify,
control, and track requirements and changes to the
requirements at any time as the project proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more
traceability tables
• These tables may be stored in a database that
relate features, sources, dependencies,
subsystems, and interfaces to the requirements
42
Generic traceability table

43
Different types of traceability tables
• Features traceability table
• Source traceability table
• Dependency traceability table
• Interface traceability table

44
 Software Requirement Specification (SRS)
• The National Bureau, IEEE with U.S. dept. of
defense jointly proposed formats for SRS along
with other SE related documentations.
• Its general formats includes following sections:
– Introduction
– Information description
– Functional description
– Behavioral description
– Validation criteria
– Bibliography & appendix
– Preliminary user’s manual
45