Software Engineering II
Essentials of Software Engineering, Frank Tsui, Orlando Karam
No project work lab
The student shall be able to:
Define stakeholder, Project Charter, Feasibility Study.
Describe different types of non-functional requirements and give an example of each.
Describe and define the seven tasks of the Requirements activity.
Describe the purpose of the throwaway prototype and why it should not be used
Describe how Infosys handles changes to signed-off requirements.
Introduction 1 hour
Prototype 0.5 hour
Total 1.5 hours
Describes what an application is meant to do
Does not describe how the program is going to do it
Well done, prevents much unnecessary rework
Requirements Management is a Key Practice Area for SEI Level 2.
Goals (from the Capability Maturity Model):
System requirements allocated to software are controlled to establish a baseline for
software engineering and management use
Software plans, products and activities are kept consistent with the system requirements
allocated to software.
Seven Stages of Requirements consist of:
Elicitation: What is the product supposed to do?
Analysis: Are the requirements clear and consistent enough to proceed?
Definition: Prepare a proposal: prototype, use cases, time estimates
Prototyping: Definition of UI prototypes.
Review: Getting feedback on prototype, use cases, feature priority
Specification: Submit formal document of the requirements
Agreement: Get signatures that the document is acceptable from customer &
OPTIONAL: INCEPTION: SHOULD WE DO THIS PROJECT?
Steps may include one or more of:
A casual conversation
Definition of Project Scope
Project Scope / Project Charter
What are the main goals of the project? (One or two sentences)
What are the major constraints or assumptions? (schedules, existing software, etc.)
What are the major deliverables and milestones?
Management authorizes project
Finance: Is there a business case for this product? Is it feasible to implement given the
Time/Resources: Is it feasible to implement the project, given resource and schedule
Technology: Can the product be built to specification? Can the system be integrated with
Feasibility Study includes:
Information assessment: Determines how to get answers to above questions
Information collection: Collects the information
ELICITATION: TELL ME MORE ABOUT THE PRODUCT…
Must answer the following questions:
What should the product be able to do?
How does the product fit the needs of the business?
How will the product be used on a day-to-day basis?
Stakeholder: Anyone with a direct or indirect influence on the system
Method 1: Interviews: Person-to-Person
Ask people questions in their area of expertise: Are you the right person?
Ask open-ended questions: What, when, where, how.
Don’t expect simple answers
Don’t rush the interviewee.
Listen, listen, listen and WRITE DOWN WHAT THEY SAY!!!
Get copies of current screens/reports and diagram required changes
Person-to-person interviews are preferable to other forms (e.g.
Method 2: Formal Meeting
All stakeholders and software team are invited
Each stakeholder is asked what functions and services they are looking for
A WRITTEN list is developed, eliminating redundancy & improving wording
Documentation (current screen/reports) are collected and required changes diagrammed
Subteams develop mini-specifications for each entry on the list
Mini-specs are then presented to full team for discussion
Customer participation in Requirements:
Traditional: Customers available to provide, inspect, approve requirements
US DOD: Technical customers work alongside developers
Extreme/Agile Programming: Customers are available to developers full time
Problems include Scope, Understanding, Volatility:
Stakeholders don’t know in detail what they want
Different stakeholders have different requirements
Stakeholders who are paying for the system are not always the main users of
Stakeholders have a different domain expertise that is not shared with
The business environment changes, causing changes to the requirements
ANALYSIS: MAKE SENSE OF THE REQUIREMENTS & PRIORITIZE
Validity checks: The stated requirements are the actual requirements
Consistency checks: Requirements do not conflict
Completeness checks: All requirements are specified (including error conditions)
Realism checks: All requirements fit in the scope of the budget and schedule
Verifiability: A test plan can be built to prove the requirements have been met.
Prioritizing features ensures that a deliverable can be made on time:
DEFINITION: BEGIN DOCUMENTING A MODEL OF THE REQUIREMENTS
Functional Requirements: Describes the services the system is to provide and
the constraints under which it must operate
Communicated in natural language plus tables or understandable diagrams
Use Case/Activity Diagrams: Describes interactions between user and
Prototype: Screen shots of forms and reports
Non-Functional requirements: Describes the system services and constraints in
Usability requirements: Look and feel, desired user group, consistency in the user
interface, user documentation and training
Performance requirements: Response time, transaction rate, memory usage
Reliability and availability: Mean time between failure, Mean time to recover
Error handling: How to handle unexpected errors
Security Requirements: Who should have access to which features.
Constraints: in tool and programming languages, followed standards, scheduling.
PROTOTYPING: IS THIS WHAT YOU WANT?
Find out more about problem and its solutions
Increases cost and time at beginning of project, but results in lower costs at
Purpose is to validate or derive system requirements
Particularly focus on not-well-understood concepts
May skip well-understood requirements.
Prototype language differs from final solution programming language
Disadvantage of Delivering Prototype as Final System:
Many not meet non-functional requirements: security, performance, reliability
Changes result in degraded system structure
Organizational quality standards are relaxed for prototypes.
REVIEW: LET’S NEGOTIATE DETAILS AND SCHEDULES.
Discuss with Customer:
Outstanding questions: We didn’t understand this part…
Prototype: Is this correct?
Use Cases/Activity Diagrams: Are these correct?
Schedule issues: This feature costs this much time…
When requirements and schedule are incompatible:
Customers rank requirements
Rough guesstimates are estimated as to feature cost
Iterations are negotiated to provide customers with features by priority
according to schedules which are realistic
Looking for all to be happy – win-win scenario
Be creative at looking how needs can be met
Don’t let it get personal – focus on the problem
SPECIFICATION: DESIGN A FORMAL AGREEMENT…
IEEE Standard for requirements documents:
o Purpose of the requirements document
o Scope of the project
o Definitions, acronyms and abbreviations
o Overview of the remainder of the document
2. General Description
o Product perspective
o Product functions
o User characteristics
o General constraints
o Assumptions and dependencies
3. Specific requirements: (covering functional, non-functional and interface
requirements: body of document)
Example User Requirements: (Taken from Ian Sommerville, Software
Engineering, 6th Edition, p. 108.)
3.5.1 Adding nodes to a design
220.127.116.11The editor shall provide a facility for users to add nodes of a
specified type to their design.
18.104.22.168The sequence of actions to add a node should be as follows:
1. The user should select the type of node to be added.
2. The user should move the cursor to the approximate node position in
the diagram and indicate that the node symbol should be added at that
3. The user should then drag the node symbol to its final position….
AGREEMENT: SIGN HERE PLEASE
The customer is given some time to review the specification (e.g., 3 days-1
Signatures from Customer, Development Team, Management indicate all are in
agreement on the stated requirements.
MANAGEMENT: DON’T FORGET ANYTHING IN THE IMPLEMENTATION…
How can we assure that all requirements are implemented? Three possibilities:
Each requirement is numbered.
In the design document, a table matches requirement to implementation AND/OR
Design inspections include relevant part of Requirements specifications as input
Code inspections include relevant parts of Design specifications as input
Each requirement is implemented as a Change Request
Each Change Request is tracked via a database.
CHANGES IN REQUIREMENTS: INFOSYS SOLUTION
Once the requirements have been agreed to and signed by customer & project
management, a requirements baseline is established.
Baseline = release or formal version
Baseline is inserted into configuration management.
What to do when requirements change? Infosys does the following:
Log the changes
Perform an impact analysis on the work products
Estimate effort needed to implement change requests
Reestimate the delivery schedule
Perform a cumulative cost impact analysis
Review the impact with senior management if cost thresholds are exceeded
Obtain customer sign-off
Rework work products (Often add change request to end of Requirements
Infosys builds into the schedule some accommodation for change requests
Change Request has the following fields:
Change Request number & Date
Brief description of change
Change category: design change contract change, performance change, …
Impact on effort, schedule.
Status of the change: Accepted or rejected with status of acceptance
Possible Prototyping Language or Evolutionary Model:
Fourth Generation Language (4GL) = Database programming language
Database query language = SQL
Interface generator creates forms for data input, display, and input validation
Spreadsheet manipulates numeric information
Report generator creates reports
Interactive form definition provides menus and links forms
Disadvantages (Ian Sommerville, Software Eng. 6th Ed. P. 184):
C program ran 10 times faster
C++ resulted in a 50% reduction in memory requirements
Prototypes poorly documented poor maintainability
Web-based interfaces can be prototyped withy a web-site editor (HTML forms)