Chapter 2

 Software Requirement Engineering

1
Software engineering Practices.
 Software Engineering is a systematic process of developing
software
.
 Practices: Is a collection of concepts , principles , methods and
tools those are considered while planning and developing the
software.

 Software Engineering implements this collection on daily

basis throughout development process of sw.

 Elements of Practices
 Concepts

 Principles

 Methods

 Tools.
2
Software Engineering Practices:
 1) Understanding a Problem( Communication and Analysis ):
 Find Stake Holder

 Understanding of unknowing ,data , functions, behaviors

for solving problems.
 Knowing compartmentalization is possible because smaller
problems can be easily understood.
 2)Planning of solutions (Modelling and Software Design)
 Find out whether same type of software exists.

 To know whether reusability is possible to solve current

problem.
 To understand whether problem can be sub divided.

 To know whether design model can be created for the same

problem.
 3)Carry out the plan (Code Generation)
 Source code is traceable to design model

 Check algorithm implemented properly

 Cod review 3
 4) Checking of the result for accuracy (Testing & Quality
assurance )

 Testing strategies are implemented .

 Check data , features ,functions and features.
 Check whether fulfills customer requirement.

 Importance of Sw Engg Practices:

 It gives scientific and engineering approach for the
software development.
 Sw engg elements helps in developing sw in specific
manner .
 SW engg practices helps in achieving expected goals of the
software developing organization.
 These practices helps in delivering best product that sustains in the
market for the longer time.
 Practices helps at every stage of sw development-
requirement analysis, modelling & design ,coding , testing and 4
Core Principles of SW Engg
 Core Principles support perfect SW engg approach.
 David Hooker has proposed Seven Core Principles .
 These principles helps to establish of SW engg practices.

 1 “The Reason at all exists”.

 Customer satisfaction is imp

 Before beginning a software project ,be sure that the sw has a
business purpose.

 2 “Keep It simple stupid/ Keep it simple but perfect”

 The design should be as simple as possible .

 There should not be too many interfaces, its difficult to construct
and implement such type of system.
 Simple Design doesn’t mean quick , easy or skip the requirement. 5
 3 “Maintain the vision”:
 There should be integrity in the thoughts of the people who work
for the project, otherwise diff people with diff views and options
,the software project may fail.
 A good architecture can hold the vision and confirms very
successful project .
 4 “What you produce ,others will consume”
 This principle states about the transparency of the
software project designing and planning.
 The project should be transparent so that the person who
work on
it understand what has done.
 Other members in the team may use the software, which is
analyzed ,designed and constructed by other persons in a
team .
 5” Be Open to the future “:
 The system with long life is always better and more preferable.
 As the hardware changes the software has to change.
 So better to use generalized software. 6
 6 “Plan ahead for reuse”:
 Reusability
 OOP, Java etc.
 Reusability saves time ,efforts ,money .
 7 Think”:
 When we think ,more ideas will come out ,it improves quality.
 Thinking completely before executing an action always
produce good result.
 We are thinking mean gaining the knowledge.
 When there is a clear thought then the system is perfect.

7
Communication Practices
 Communication Practices is the initial stage that collects or
gathers the requirements from the customer.
 Communication is the most important activity as it is a one of
the important for deciding the success or failure of the project .
 Requirement analysis needs a huge communication .
 Communication is the backbone for any organization that
develops the software.
1. “Listen Carefully”:
1. To understand customers requirement .
2. Listening ensures proper data collection.
3. Don’t be in hurry ,ask questions for doubt .
4. Try to avoid interruption.
2. “Be prepared before you communicate”:
1. Prepare agenda for meeting
2. Prepare all issues for meeting.
3. Try to understand problem statement in detail.
8
3. “Be prepared to facilitate the activity”
1. Solve the conflicts if any
4. “ Face to Face communication”:
1. Better than documents and drawings
5. “ Take Notes and document Decision”:
1. Write down all important points and issues raised in meeting .

2. These points and issues can be referred in next meeting.

6. “Strive for collaboration”:

1. For better teamwork the collaboration in team member is essential .

2. Collaboration is achieved when the collective knowledge of team

member is united to illustrate the system functions.
7. “Stay Focused ,modularize your discussion “:
1. It is necessary to keep limited people in meeting become
people will bounce the topic .
2. Facilitator (leader) should direct meeting in required direction.

8. “If something is unclear draw the picture “

9. “Keep the discussion to move on”

10. Negotiation is successful when both parties agree- function, 9
priorities ,deliveries
2.4 Planning Practices
 Any big task needs a planning for its successful execution.
 Planning become a guideline to the team & good planning leads
to successful result.
 Software planning includes scheduling cost estimation and
risk
analysis.
 Planning activity is a set of management and technical practices .

 Planning includes following activities:

1. Identification of what resources are required & Exact calculation
of it.
2. Cost Estimation
3. Project Scheduling with alternate plans.
4. Risk identification and management solutions.
5. Identification of technology & related issue.
6. Commencement date and delivery date.
10
1. “ Understand the scope of the project”:
1. Planning provides the exact goal for sw development..
2. Planning should be done considering the future scope.
3. Scope is mainly to understand the range in which project is
developing and the boundaries of the project in which team
have to work.
2. “involve the customer in planning activity”:

1. Delivery date of project , project increments.

2. Customer should be involved in each activity of Development.
3. For giving priorities in development,
4. To know project hurdles.
3. Recognize that planning is iterative
1. In case of iterative model customer can suggest changes
afeter every delivery hence developer must accept that
planning is iterative activity.
2. Planning is always changing and it should accommodate
changes. 11
4. Estimate on what you know :
1. Team can work efficiently if efforts ,tasks and cost is reliable.
2. If information is vague or unreliable ,estimation will be
equally unreliable
5. Consider risk as you define plan:
1. Risk is unwanted event that may or may not occur.
2. It results in unwanted effects or outcomes .
3. It has high impact on project .

6. Be realistic:
1. Delays ,mistake and wrong decision.
2. Estimation of the project must be realistic.
3. Plan should be dynamic.
7. Adjust granularity as you define the plan:
1. Granularity means the level of detail.
2. Activities that do not occur longer time doesn’t require fine
granularity . 12
8. Define how you are going to achieve the quality:
1. Conduct Formal technical review.
2. FTR applied at requirement analysis ,design , coding ,testing etc.
3. It is not a problem solving activity but it finds out defects.
9. Describe how you accommodate changes:
1. Good quality software must be well planned to accommodate
changes.
2. Changes in the project affects the cost and schedule.
3. Changes in the sw are easy to do if found in early stage .
10. Always keep track on the plan and make changes as
required.

13
Planning Principles:
Boehm Suggests WHH principles

1. Why is system being developed :

1. This principle states that focuses the basic aim.
2. Does the business purpose make justice with the expense
of people ,time and money.
2. What will be done :
1. Objective of this principle is to find out technical feasibility of
the
project or the functionality of system.
2. Find out the functionality.
3. When it will be accomplished
1. Time schedule
2. Timeline for important project task
4. Who is responsible for a function
1. Focus on responsibility of each team member 14
5. Where are they organizationally located ?
1. Focuses on the roles and responsibilities of user and
customer .

6. How job will be done technically and managerially.

1. This focuses on the product by technical and management point
of
view
2. Managerial and technical strategy for the project must be defined.

7. How much of each resource is needed.

1. Resource planning
2. Estimation

15
Modelling Practices
 Models are created for the better understanding of the actual entity
or design .
 e.g. Building
 Modelplan
must be capable of representing the information that
software
transforms, the architecture and functions.
 Model must accomplish the different levels of abstraction
and representing it at more technical level.
 In Software engineering two types of models
 Analysis Models

 Design Models
 Design Models Analysis Model
 The Architecture Information Domain
 The User Interface Function Domain
 Component Level Behavior Domain

16
Analysis Modelling Principal
1. The information domain of problem must be clearly
represented and understood :
1. Analysis Model use DFD to show such information.
2. Information Domain includes following things:
1. Input Flow into system
2. Output Flow from the system
3. Data Collection by data store to collect data in the system .
2. Function of the software must be defined clearly:
1. Functions transforms the input flow to output flow.
2. The process specifications functions provides function
details.
3. These functions must be clearly defined.
3. Behavior of the system must be clearly defined :
1. State transition diagram are used to represent the
behavior of the
system.
17
2. The behavior of the system shows how the system
4. The models that depict function, information, and
behaviour must be partitioned in such a manner that
uncovers details in a layered fashion
1. Complex and critical problems are difficult to solve, because of
we use divide and conquer approach.
2. Large, complex and critical problems are divided into
subproblems until each sub problems is relatively easy to
understand.
3. This approach is called partitioning.

5. Analysis task should move from essential information

towards implementation details
eg. For voice input, video game might be used

18
Design Modelling
 Design modeling is equivalent to architectural plan of the house,
It provides the correct specification for construction.

 It represents characteristics of software those help for effective

implementation of software.

 Design step includes the design of the flowchart for the

pictorial representation of requirement.

 Design model includes

 Architectural Design

 User Interface Design

 Component Level details.

19
1. Design should be traceable from analysis model.
2. Consider the architecture of the system to be built.
Architecture design shows following architecture styles
1. Data centered architecture –
Client sw accessing central database.
2. Data Flow Architecture –
1. Input data flow after processing generates
output data.
3. Main/ subprogram Architecture
1. Showing hierarchical relationship between main
programs and its subprograms.
3. Design of data is an important as design of functions
1. Design of data is an important factor.
2. The Data designing shows relationship between
different data objects.
3. Design model includes “Entity Relationship Diagrams” to show
relationship between diff data objects.
20
4. The interfaces must be designed with care
1. In a system data may flow from one component to another
component.
2. Also data may flow from external environment to system, so
the internal and external interfaces must be designed properly.

5. User interface design must satisfy all need of end user .

6. Component level design should be functionally independent :

 Functions should be designed such that all task of the sw
should be
closely related called “Cohesion”
 Functions should be highly cohesive.
7. Components should be loosely coupled to one another and to
the external environment.
1. Interconnection between different components should be
minimum.
8. Designed modules should be easily understandable.
21
Construction Practices
 Construction activity includes coding & testing .
 Deign details are implemented by using any programming
language
 e.g. c, c++, java cobol, VB,Basic etc
 Using automated toos like Microsoft Front Page ,code is
automatic geneated.
 VC++ generates Executable code.

 Testing :
 To check whether the flow of coding is correct.
 To check the errors in the code.
 To Check whether the program is giving expected output.
 Sequence of testing
 Integration Testing

 Validation Testing

 Acceptance Testing
22
Coding Principals
1. Preparation Principles:

1. Understand the problem for which you are trying

2. Understand the basic design and the concept for the

same.

3. Select appropriate programming language .

4. Select Programming environment that will be suitable for

writing the code.

5. Create set of unit tests.

23
2. Coding Principles:
Principles to be followed while writing the code.
1. The algorithm you are using must follow structured
programming principles.
2. Use suitable data structure those will fit for coding.
3. Software architecture & interfaces are to be implemented as
per design specification.
4. Keep minimum nested conditions.
5. Keep minimum nested loops.
6. The variable name should be meaningful and as per standards.
7. Code must be self documented i.e. provide help comments for
each
steps.

3. Validation Principles:
1. Conduct the unit test also when module produce exact output.
2. Refactor the code if necessary.
24
Testing Principles
Software testing ensures
 Quality of the software
 Customer Satisfaction
 Removal of errors
 Verification and Validation of Sw product.
 Compatibility of the software.

 Principles:

1. All test should be traceable to customer requirements.

2. Test must be well planned before starting testing work.
3. Perito Principle is applicable to sw engineering : 80-20
4. Testing should begin in the small and progress towards in the large.
5. Accept that testing of every combination of paths is not possible

25
Software Deployment
 Software Deployment activity consist of three main activities delivery,
support and Feedback.

 Deployment occurs many times.

 Each and every delivery cycle facilitate end user or customer
with increment.
 Every feedback offers significant guidance that result in editing
and modifying functions.
 Support cycle includes removing bugs.
1. Deployment Principles :
1. Manage customers expectations.
2. Assemble and test complete delivery package.
1. All executable files of developed sw
2. All installation procedures
3. All operational features and help.
4. Essential manuals
5. Hardware, os , network component.
26
3. “Record keeping mechanism must be established for
customer support”

4. Provide essential instructions , documentations and manual

1. Actual project delivery includes all documentations ,help files, and
guidance for handling the software by user.
5. Don’t deliver any defective or buggy software to the
customer .

27
Concept of requirement engineering
 Requirement engineering is used for better understanding of
the problem that software is going to start.

 Requirement engineering helps in understanding the following

points.
 Business impact of software

 Exact expectations of customer.

 Interaction of user with system.

 All stakeholder should participate in Requirement engineering .

 If Requirement analysis is wrong then design will be wrong and
sw
will not satisfy the customer requirement.
 Hence if Requirement engineering is wrong then every
upcoming
 Inceptionphase will be wrong.
Elicitation Elaboration
 Requirement
 Negotiation engineering functions
Specification Validation
 Requirement Management.
28
1. Inception:
 Means beginning.
 Well beginning is half done .but for sw engg “from where to start”

 Requirement engineering is communication intensive activity.

 Customer and developer meets & decides the scope of the sw

with
the following aim:
1. To have the basic understanding of the problem
2. To how who will use this software.
3. To know the precise nature of the problem from customer side.
4. To maintain the effectiveness of preliminary communication.
5. TO have collaboration between customer and developer.
Developer must ask following questions:
6. Who is behind the request for this work
7. Who will use the solution
8. What will be the economical benefits of a successful solution
9. Is there another solution for the same problem
29
2.
Elicitation
 Elicitation means “ to draw out the truth or reply from anyone”.
 It is the task that helps the customer to define what is required.
 It is difficult to know what customer exactly wants because
of following problems.
 Problem of scope
 Problem of understanding
 What is needed
 Capabilities and limitations
 Conflicting requirements.
 Problem of volatility- changing of requirement from one state to
another.
3. Elaboration:
 Means “to work out in detail”. It is called as analysis modeling
action.
 Information is expanded which is collected from inception and
elicitation
 New Requirement engineering activities focuses on 1Functions
2features 30
4. Negotiation:
1. Negotiation means discussion on financial and commercial
issues.
2. Customer and stakeholder discusses on
1. To rank the requirements
2. To decide priorities
3. To decide risks
4. To finalize project costs
5. Impact of above issue on the project cost and delivery date.
5. Specification:
1. Specification is a final work produced by requirement engineering
2. Specification may be in diff forms
1. A written document
2. A set of graphical model
3. A formal mathematical model
4. A collection of scenarios
5. A prototype
6. Or any combination of above
31
6. Validation:
1. Means checking customers expectations
2. Requirement validation checks following :
1. Are All requirement stated clearly ?
2. Are the requirements misinterpreted ?
3. Does the requirements violate any system domain constraint.
4. Is the system requirement traceable to the system model that
is created ?
5. Are the requirements associated with the
performance , behavior and operational characteristics
?
7. Requirement Management:
 It helps the project team to identify ,control and tracl requirements
and changes in requirement.

 The requirement management starts with identification and every

requirement will be assigned a unique or distinct identifier .
 Each trace table relates the requirements to one or more aspect of 32
the system or it environment .
Traceability Table
 .

33
Following are different traceability tables :

1. Features traceability table :

1. Shows how requirements relates to important product features

observed by customer.
2. Source traceability table :
1. Identifies the source of each requirement.
3. Dependency traceability table :
1. Shows relationship among requirements.
4. Subsystem traceability table :
1. Classify requirements by subsystem .
5. Interface traceability table :
1. Shows how requirements related to internal as well as
external interfaces.

34
Concept of SRS
 The software requirement specification are generated at the end .

 SRS gives the information about the software requirement in specific

form
 It contains the important information for the sw development.
 SRS contains the deep understanding of what is exact requirement.

 SRS contains the following important details:

 Complete or total information description

 A full functional description

 The representation of system behavior

 Indication or sign of performance

requirements and design constraints
 Suitable validation criteria

 Any other information related to

35
requirements.
 General Formats of SRS
 National bureau, IEEE with U.S. Department of Defense .
 General format includes following Sections
1. Introduction:
1. Introduction of sw requirements specification .
2. It is used to state objective and goals of SRS.
3. It could be used to define scope of the planning and document it.
2. Information Description
1. This section provides the complete description of the problem.
2. Documentation of information content ,flow , structure .
3. Interfaces required for human interactions , hw and sw
described.
3. Function description:
1. Detailed description of every function .
2. This section contains
1. Processing narratives
2.
3. Performance
Representation characteristics
of structure of overall 36
4. Behavioral Description:
This section checks the operation of the software as a result of
external events and internally produced control characteristics.
5. Validation criteria:
This helps in taking implicit review of the system.
6. Bibliography and Appendix:
This section contains the references required to document the
software related information .
1. SW engineering document
2. Technical references.
3. Vendor literature
4. Standards
5. Appendix section contains
1. Tabular data 2. Algorithm 3.charts 4. Graphs
5.Other relevant material
7. Preliminary Users Manual:
This is used as black box .The major focus is on user input and result
output 37