This document provides an overview and recap of requirements engineering. It discusses requirements management tasks like change and risk management. It then outlines the key topics covered in requirements engineering, including principles, frameworks, stakeholders, goals, models, and quality assurance. It also discusses defining a project plan, including infrastructure elements, project contents, and estimating budgets. Finally, it covers factors that affect software pricing strategies and defining project management elements like change management.

1. Requirements Engineering:
Wrap-up
CECS 542
Dr. Birgit Penzenstadler 1
Photo credit: Ricardo Gomez Angel, unsplash

2. Recap =me!
• Requirements Management
– What tasks does it entail?
– Change Management – how?
– Risk Management – how?
Dr. Birgit Penzenstadler 2

3. Requirements Engineering – Outline
• WHY do we need Requirements Engineering and what is it?
• Principles: Defini=ons, process, roles, problem/solu=on view, ar=fact orienta=on
• System Models: Decomposi=on and abstrac=on, system views
• Frameworks: What reference structures can I use for requirements?
• Business Case Analysis: Why are we building this system?
• Stakeholders: Who are the people to talk to about requirements?
• Goals and Constraints: What are the major objec=ves for the system?
• System Vision: What exactly do we want to achieve?
• Domain Models: What are the surrounding systems ours interacts with?
• Usage Models: How will the system interact with the user?
• SoYware quality models: How to determine the quality characteris=cs?
• Quality requirements: How to specify which quali=es need to be met?
• Process requirements: How to specify constraints for development?
• Towards a system specifica=on: How to hand over to design?
• Quality assurance: How to ensure that RE is done in a good way?
• Change management: How to evolve requirements?
• Wrap-up: How to put it all together
Dr. Birgit Penzenstadler 3

4. Project plan: What to define?
Dr. Birgit Penzenstadler 4 CSULB spring 2015
Artwork: Jonathan Harris

5. Project plan: What to define?
Infrastructure plus project content.
Dr. Birgit Penzenstadler 5
Process Task
Next Process
A
This has an
associated...Note or
suggestion
Process
model
Ac=vi=es/ Methods Ar=facts
Tools Roles
Milestones

6. Fill in…
Dr. Birgit Penzenstadler 6

7. Sounds familiar?
Guess what… ar=facts!
Dr. Birgit Penzenstadler 7
Context Layer
System Layer
Requirements Layer
Stakeholder Model Objectives
& Goals
Constraints
& Rules
!
!
!
!
!
Data Model
E
A
A
A
E
System Vision
Functional
Hierarchy
Architecture Overview
System
Function Model
Fun 1
Fun 2
Component Model
C C
Data Model
E
A
A
A
E
Behaviour Model
Business Case
Deployment Requirements
System Constraints
Domain Model
Service ModelUsage Model
Quality Requirements
Risk List
Project Scope
Process Requirements
Glossary
Glossary
Glossary

8. Let’s do it: Infrastructure
1. Ar=facts
2. Ac=vi=es
3. Roles
4. Milestones
5. Tools
Dr. Birgit Penzenstadler 8

9. Let’s do it: Project Contents
1. Mission
2. Scope
3. Stakeholders
4. Goals
5. Constraints
Dr. Birgit Penzenstadler 9

10. Let’s do it: Budget
It’s spreadsheet o’clock!!
1. (Es=ma=on of required hardware)
2. (Es=ma=on of required soYware)
3. Es=ma=on of development work
Dr. Birgit Penzenstadler 10

11. SoYware pricing
• Es=mates are made to discover the cost, to the
developer, of producing a soYware system.
– You take into account, hardware, soYware, travel,
training and effort costs.
• There is not a simple rela=onship between the
development cost and the price charged to the
customer.
• Broader organisa=onal, economic, poli=cal and
business considera=ons influence the price
charged.
11
Ian Sommerville, SoYware Engineering, 9th Edi=on

12. Factors affec=ng soYware pricing
Factor Description
Contractual terms A customer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects.
The price charged may then be less than if the software
source code is handed over to the customer.
Cost estimate
uncertainty
If an organization is unsure of its cost estimate, it may
increase its price by a contingency over and above its
normal profit.
Financial health Developers in financial difficulty may lower their price to
gain a contract. It is better to make a smaller than normal
profit or break even than to go out of business. Cash flow is
more important than profit in difficult economic times.
12
Ian Sommerville, SoYware Engineering, 9th Edi=on

13. Factors affec=ng soYware pricing
Factor Description
Market opportunity A development organization may quote a low price
because it wishes to move into a new segment of the
software market. Accepting a low profit on one project may
give the organization the opportunity to make a greater
profit later. The experience gained may also help it develop
new products.
Requirements volatility If the requirements are likely to change, an organization
may lower its price to win a contract. After the contract is
awarded, high prices can be charged for changes to the
requirements.
13
Ian Sommerville, SoYware Engineering, 9th Edi=on

14. Pricing strategies
• Under pricing
– A company may underprice a system in order to
gain a contract that allows them to retain staff for
future opportuni=es
– A company may underprice a system to gain
access to a new market area
• Increased pricing
– The price may be increased when a buyer wishes
a fixed-price contract and so the seller increases
the price to allow for unexpected risks
14
Ian Sommerville, SoYware Engineering, 9th Edi=on

15. Pricing to win
• The soYware is priced according to what the
soYware developer believes the buyer is willing
to pay
• If this is less that the development costs, the
soYware func=onality may be reduced
accordingly with a view to extra func=onality
being added in a later release
• Addi=onal costs may be added as the
requirements change and these may be priced at
a higher level to make up the shormall in the
original price
15
Ian Sommerville, SoYware Engineering, 9th Edi=on

16. Then: Define for Project Management
• Change Management
• Risk Management
• Valida=on & verifica=on
• Version & configura=on management
• Claim management
• Support for distributed RE
Dr. Birgit Penzenstadler 16

17. Details: Requirements Nego=a=on
Dr. Birgit Penzenstadler 17