Software Engineering

Sobia Iftikhar Week 05

[Link]@[Link]
Content
• Requirement Engineering
• Estimation Techniques
• Wide band Delphi
• Work Breakdown Structure
 Class 13
10-March-2021
Requirements Specification
Ways of writing a 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
language template. 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. 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

• should write the requirement in one or two sentences of natural language.

• using “shall.” for essential requirements.
• Desirable requirements are not essential and are written using “should.”
• Use text highlighting (bold, italic, or color) to pick out key parts of the requirement.
• Do not assume that readers understand technical, software engineering language. It is easy for words
such as “architecture” and “module”
 Structured specifications
• 1. A description of the function or entity being specified.

• 2. A description of its inputs and the origin of these inputs.

• 3. A description of its outputs and the destination of these outputs.

• 4. Information about the information needed for the computation or

other entities

• in the system that are required (the “requires” part).

• 5. A description of the action to be taken.

• 6. If a functional approach is used, a precondition setting out what

must be true before the function is called, and a Postcondition
specifying what is true after the function is called.

• 7. A description of the side effects (if any) of the operation

Mathematical Notations
• computations of the insulin requirement
Graphically Language
System Requirements Documentation
Users of a requirements document
Requirements validation
Requirements validation
• Requirements validation is the process of checking that 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?
• Realism. Can the requirements be implemented given available budget and
technology
• Verifiability. Can the requirements be checked?
 Requirements validation techniques

• Requirements reviews
• Systematic manual analysis of the requirements.

• Prototyping
• Using an executable model of the system to check requirements. Covered in Chapter 2.

• Test-case generation
• Developing tests for requirements to check testability.
Requirements change
Changing requirements
• The business and technical environment of the system always changes after installation.
• New hardware may be introduced, it may be necessary to interface the system with other systems, business
priorities may change (with consequent changes in the system support required), and new legislation and
regulations may be introduced that the system must necessarily abide by.

• The people who pay for a system and the users of that system are rarely the same people.
• System customers impose requirements because of organizational and budgetary constraints. These may
conflict with end-user requirements and, after delivery, new features may have to be added for user support
if the system is to meet its goals.
Requirements evolution
Requirements change management
• Deciding if a requirements change should be accepted
• Problem analysis and change specification
• During this stage, the problem or the change proposal is analyzed to check that it is valid. This analysis is fed back to
the change requestor who may respond with a more specific requirements change proposal, or decide to withdraw the
request.
• Change analysis and costing
• The effect of the proposed change is assessed using traceability information and general knowledge of the system
requirements. Once this analysis is completed, a decision is made whether or not to proceed with the requirements
change.
• Change implementation
• The requirements document and, where necessary, the system design and implementation, are modified. Ideally, the
document should be organized so that changes can be easily implemented.
Requirements change management
• Examples of open-ended questions:
• Where would you like your business to grow from here?
• What would success look like to you?
• What campaigns are out there right now that caught your eye, and for what reasons?
• What are a couple day-to-day practices of yours that people can implement for greater success/fulfillment in their own lives?
• Can you give me a few dates for a follow-up call?
• Examples of closed-ended questions
• Are you satisfied with your current sales numbers?
• What is your #1 goal?
• Did you like your competitor’s latest campaign/commercial?
• Where can someone go to learn more about what you do?
Which on open and close side
Software Project Management
• What is estimation?
• The project manager must set expectations about the time required to complete the software
among the stakeholders, the team, and the organization’s management.
• If those expectations are not realistic from the beginning of the project, the stakeholders will not
trust the team or the project manager.
Estimation Techniques

Work Breakdown
Structure (WBS)

Wideband Delphi
What is WBS?
• Breaking work into smaller tasks is a common productivity technique used to make the work more
manageable and approachable.
• For projects, the Work Breakdown Structure (WBS) is the tool that utilizes this technique and is
one of the most important project management documents. It singlehandedly integrates scope, cost
and schedule baselines ensuring that project plans are in alignment.

25
 The Work Breakdown Structure
• Used as a basis for a number of in particular to produce the subsidiary plans of
the Project Management Plan.
WB

• The WBS is a deliverable-oriented hierarchy of decomposed project

S

components.
• The WBS is a representation of the detailed project scope statement that
specifies the work to be accomplished by the project.
• The elements comprising the WBS assist the stakeholders in viewing the end
product of the project.
• The work at the lowest-level WBS component is estimated, scheduled, and
tracked.
 When should we develop WBS?
• Once the project Scope is agreed (finalized) then before starting the
project we need to plan various components (activities) of software
development project.
 WBS Guidelines
• Accurate and readable project organization.
• Accurate assignment of responsibilities to the project team.
• Indicates the project milestones and control points.
• Helps to estimate the cost, time, and risk.
• Illustrate the project scope, so the stakeholders can have a better understanding of the same.

29
Guidelines - continued
• Include three types of project work
• Product
• Specifically assigned to a physical product as a unique deliverable
• This subset is sometimes referred to as the product breakdown structure
• Integration
• When products are brought together as a unit
• Can be at any level
• Support
• Level of Effort, Administration, Expenses, Improvement Practices, Contractor
Management
 Steps to build a WBS
• Begin with the Charter, focusing on Objectives and Deliverables
• Break the main product(s) down into sub-products

• Set the structure to match how you’ll manage the project

• Lowest level not too detailed, not too large
• Is there a need for Integration?
• Identify support activities
• Check for completeness - is all the effort included?
• Develop a coding structure if needed
• Assign work package managers

31
WBS Formats
• 2 Formats
• Outline (Indented Format)
• Graphical Tree (Organizational Chart)
 Displaying the WBS
Example of outlined WBS.

33
 Displaying the WBS
Example of Chart WBS.

34
• [Link]
• [Link]
• [Link]
 Example WBS
• Redecorate Room
• Prepare materials
• Buy paint
• Buy a ladder
• Buy brushes/rollers
WB

• Buy wallpaper remover

S

• Prepare room
• Remove old wallpaper
• Remove detachable decorations
• Cover floor with old newspapers
• Cover electrical outlets/switches with tape
• Cover furniture with sheets
• Paint the room
• Clean up the room
• Dispose or store left over paint
• Clean brushes/rollers
• Dispose of old newspapers
• Remove covers
Wideband Delphi
• Wideband Delphi is a process that a team can use to generate an
estimate
• The project manager chooses an estimation team, and gains consensus among that team on the
results
• Wideband Delphi is a repeatable estimation process because it consists of a straightforward set
of steps that can be performed the same way each time
Wide Band Delphi
• For each task, each estimator provide the:
• Optimistic effort: the least cost and least time
• Pessimistic effort: the most cost and the time
• Expected effort: the realistic forecast
Calculate the average of these estimates form each estimators
E = 0+P+4B/6
The Wideband Delphi Process

Assemble
Estimation Tasks &
Meeting Review
Results
Individual
Estimation

Kickoff
Meeting

Planning
The Wideband Delphi Process
• Step 1: Choose the team.
• The project manager selects the estimation team and a moderator. the team
should consist of 3 to 7 project team members.
• The moderator should be familiar with the Delphi process, but should not have a stake in the outcome of
the session if possible.
• If possible, the project manager should not be the moderator because he should ideally be part of the
estimation team.
Step 2: Kickoff Meeting
• The project manager must make sure that each team member understands the Delphi process, has
read the vision and scope document and any other documentation, and is familiar with the project
background and needs.
• The team brainstorms and writes down assumptions.
• The team generates a WBS with 10-20 tasks.
• The team agrees on a unit of estimation.
 Step 3: Individual Preparation
• Each team member independently
generates a set of preparation results.

• For each task, the team member writes

down an estimate for the effort required
to complete the task, and any additional
assumptions he needed to make in order
to generate the estimate.
Estimation form for every person

47
Step 4: Estimation Session
• The moderator calls the Estimation team for the Estimation meeting. If any of the Estimation team
members respond saying that the estimates are not ready, the moderator gives more time and
resends the Meeting Invite.
• The moderator begins the estimation meeting by collecting and charting the participants'
individual estimates. Each participant's total project estimate is shown as an X on the "Round 1"
line. The initial estimates probably will cover a frighteningly large range.
Step 5: Assemble Tasks
• The project manager works with the team to collect the estimates from the team members at the
end of the meeting and compiles the final task list, estimates and assumptions.

Step 6: Review Results

• The project manager reviews the final task list with the estimation team.
Summarized result of estimation

50