Requirements Engineering - Wrap-up: Putting it all together

Requirements Engineering: Wrap-up

CECS 542 Dr.BirgitPenzenstadler 1

Photocredit:RicardoGomezAngel,unsplash

Recap=me!

•  RequirementsManagement– Whattasksdoesitentail?– ChangeManagement–how?– RiskManagement–how?

Dr.BirgitPenzenstadler 2

RequirementsEngineering–Outline•  WHYdoweneedRequirementsEngineeringandwhatisit?•  Principles:Defini=ons,process,roles,problem/solu=onview,ar=factorienta=on•  SystemModels:Decomposi=onandabstrac=on,systemviews•  Frameworks:WhatreferencestructurescanIuseforrequirements?•  BusinessCaseAnalysis:Whyarewebuildingthissystem?•  Stakeholders:Whoarethepeopletotalktoaboutrequirements?•  GoalsandConstraints:Whatarethemajorobjec=vesforthesystem?•  SystemVision:Whatexactlydowewanttoachieve?•  DomainModels:Whatarethesurroundingsystemsoursinteractswith?•  UsageModels:Howwillthesysteminteractwiththeuser?•  SoYwarequalitymodels:Howtodeterminethequalitycharacteris=cs?•  Qualityrequirements:Howtospecifywhichquali=esneedtobemet?•  Processrequirements:Howtospecifyconstraintsfordevelopment?•  Towardsasystemspecifica=on:Howtohandovertodesign?•  Qualityassurance:HowtoensurethatREisdoneinagoodway?•  Changemanagement:Howtoevolverequirements?•  Wrap-up:Howtoputitalltogether


Projectplan:Whattodefine?

Dr.BirgitPenzenstadler 4CSULBspring2015

Artwork:JonathanHarris

Projectplan:Whattodefine?Infrastructureplusprojectcontent.


Process Task

Next Process

A This has anassociated...Note or

suggestionProcess model

Ac=vi=es/M

etho

ds

Ar=facts

Tools

Roles

Mileston

es

Fillin…


Soundsfamiliar?Guesswhat…ar=facts!


Context Layer

System Layer

Requirements Layer

Stakeholder Model Objectives & Goals

Constraints & Rules

!

!

!

!

!

Data Model

EA

A AE

System Vision

Functional Hierarchy

Architecture Overview

System

Function ModelFun 1

Fun 2

Component Model

C C

Data Model

EA

A AE

Behaviour Model

Business Case

Deployment Requirements

System Constraints

Domain Model

Service ModelUsage Model

Quality Requirements

Risk List

Project Scope

Process Requirements

Glossary

Glossary

Glossary

Let’sdoit:Infrastructure

1.  Ar=facts2.  Ac=vi=es3.  Roles4.  Milestones5.  Tools


Let’sdoit:ProjectContents

1.  Mission2.  Scope3.  Stakeholders4.  Goals5.  Constraints


Let’sdoit:Budget

It’sspreadsheeto’clock!!1.  (Es=ma=onofrequiredhardware)2.  (Es=ma=onofrequiredsoYware)3.  Es=ma=onofdevelopmentwork


SoYwarepricing

•  Es=matesaremadetodiscoverthecost,tothedeveloper,ofproducingasoYwaresystem.–  Youtakeintoaccount,hardware,soYware,travel,trainingandeffortcosts.

•  Thereisnotasimplerela=onshipbetweenthedevelopmentcostandthepricechargedtothecustomer.

•  Broaderorganisa=onal,economic,poli=calandbusinessconsidera=onsinfluencethepricecharged.

11

IanSommerville,SoYwareEngineering,9thEdi=on

Factorsaffec=ngsoYwarepricing

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


Factorsaffec=ngsoYwarepricing

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


Pricingstrategies

•  Underpricing– Acompanymayunderpriceasysteminordertogainacontractthatallowsthemtoretainstaffforfutureopportuni=es

– Acompanymayunderpriceasystemtogainaccesstoanewmarketarea

•  Increasedpricing– Thepricemaybeincreasedwhenabuyerwishesafixed-pricecontractandsothesellerincreasesthepricetoallowforunexpectedrisks

14


Pricingtowin•  ThesoYwareispricedaccordingtowhatthesoYwaredeveloperbelievesthebuyeriswillingtopay

•  Ifthisislessthatthedevelopmentcosts,thesoYwarefunc=onalitymaybereducedaccordinglywithaviewtoextrafunc=onalitybeingaddedinalaterrelease

•  Addi=onalcostsmaybeaddedastherequirementschangeandthesemaybepricedatahigherleveltomakeuptheshormallintheoriginalprice

15


Then:DefineforProjectManagement

•  ChangeManagement•  RiskManagement• Valida=on&verifica=on• Version&configura=onmanagement• Claimmanagement• SupportfordistributedRE


Details:RequirementsNego=a=on


Requirements Engineering - Wrap-up: Putting it all together

Software

Transcript of Requirements Engineering - Wrap-up: Putting it all together