1 requerements in the software lifecycle. 2 requirements challenge complex hci : always complicate...

1

Requerements in the Software Lifecycle Requerements in the Software Lifecycle

2

Requirements Challenge• Complex

HCI : Always complicate and complex

• Eliciting Requirements Need to be always exploring

Many possible solutions

No right or wrong

What is the problem again ?

3

Once more What is RE ?• A systematic process of developing requirements

through an iterative and co-operative process of analyzing the problem, documenting the resulting observations in a variety of representation formats, and checking the accuracy of the understanding gained.

[MaCaulay – Requirements Engineering (applied Computing)]

4

Software Myths (From Easterbrook Lectures)

• Cost of Software is Lower than cost of physical devices

• Software is easy to change

• Computers are more reliable than physical devices

• Software can be formally proved to be correct

• Software reuse increases safety and reliability

• Computers reduce risk over mechanical systems

5

Why do we develop a software ?• Competition, critical facts

• New technology has been developed

• New Requirements

• Company is growing Business is changing

• Something Changed in your world

• Continue a previous project

6

Professional Responsibility• Competence

Never misrepresent your level of competence

• Confidentiality Respect confidentiality of ALL Stakeholders

• Stakeholders

How customers are linked and how is it important ?

Who are the Stakeholders ?

customerusers

clients

OwnerEspecialist

Partner

Third party clients

Investor

clients

Non-clients

7

Professional Responsibility• Intellectual property rights

Respect protection on ideas, design, patterns ….

• Data Protection Check the Law to see how personal data should be handled

Whatever you learn here should be constantly check during the whole lifecycle

8

Managing Projects• What can a Manager Control ?

Resources - Money, Personal, tools, facilities ..

Product – What and how the system will do things – (Control the scope)

Time create detailed schedules Check milestonesChange schedule and milestonesBe pro-active

Risk What are the risks in the project

o Different scope/solutions may have different risksWhich risks can we live withIf risk is too high how should we proceede

o Brace for collision ?o Revisit the scope or possible alternatives ?

9

Management• Measure !!

If you can’t measure your process/project you can not manage it

• Have a clear notion of the desired goals and objectives

• Plan ahead

• Assume things will go wrong

• Monitor and adjust it as frequently as needed

• Keep the environement Calm

Productive

Informed (when possible)

10

Why do we start a project ?• Why ?

Problem drivenExisting system present problemsIncompleteness

Changes in the domainWhen something relevant arises in business or its environmentCurrent system can not handle new businesses Change in Law

New opportunitiesNew technology can improve business New markets have arisenNew upper management

11

Source of Requirements• Customer

A specific customer have a specific need

• Market May want to sell to a large number of clients (e.g. ERP)

Need to reach new customers

Marketing identifies ne wopportunities

• Social Related Systems that do not seek profit

Open software Scientific research

• Mix We do have a client but we want to leave it open to explorer larger set

of customers late.

12

Most Common types of systems• Information systems

Support an organization

Database is part of the system

More than 70% of all software

Payroll

Accounting

Customer relation

Student Enrollment

• Control Systems Control process (hardware) in real time

Flight Control

Nuclear power plant

Elevators

• Generic Provide services to other systems

Search enginesCredit Card processingM

13

Software Lifecycles• Waterfall

14

Software Lifecycles

15

Software Lifecycles

1616

Rational Unified Process

17

System Lifecycle

18

Software lifecycle

19

Software Lifecycles

20

Software Lifecycles

21

What is a System• Part of a reality that can be observed and interact with the

environment Every system has a boundary

Get inputs and send outputs

Almost always composed of smaller sub-systems

• Examples Cars, weather, universe, Cardiovascular

Operating Systems

Database Servers

Organizations

• Not Systems Numbers

Letters

22

23

Types of Systems• Natural Systems

Ecosystems, weather, human body

• Abstract Systems Mathematical equations, computer programs

• Designed Systems Cars, planes, phones, internet

• Human Activity Systems Organization, markets, clubs

• Information Systems MIS

Transaction Processing

Real-Time Control

24

Software Systems• Hard to define precisely

• Composed of abstract ideas

• Different people may have different understandings

• The system doesn’t really exists Talking about systems helps to understand it

• The system is a Theory of how some part of the world operates

25

System Boundary• The part of the world that interacts with the system

Every system has a subsystem

The environment in itself is a system

• Choosing Boundaries Maximize modularity

Telephone system – switches, phone lines, handsets, users, account

Desktop Computer - ?

TipsExclude things that have no functional effect on the systemExclude things that influence the system but cannot be influenced or

controlled by the systemInclude things that can be strongly influenced or controlled by the system

26

A Place to Start• Nowadays almost always there is a system in place

Studying what we have prompts to requirements and helps to avoid past mistakes

• Using what we have Can reduce costs Makes it easier to break problems downs

But Can mislead you too !!

• Is the problem presented to us the real problem ?

27

Starting in a Nutshell• Stakeholders

How customers are linked and how is it important ?

Who are the Stakeholders ?

customerusers

clients

OwnerEspecialist

Partner

Third party clients

Investor

clients

Non-clients

28

Starting in a Nutshell• Boundaries

How do you scope the problem ?

How far should we go ?

Time constraints ?

Budget constraints ?

• Goals and Scenarios Helps understanding what, who, when, why

May not be too easy to determine

• Feasibility Cost vs Benefit analysis

• Risk Continuous Risk Management

29

vz

30

• Subject World Things that need to be used in the information system

Account, Transaction in a bank account, Collision Alert

• Usage World The environment where the future system will operate

People

o Managero Clerko Customer

Business Process

o Withdraw moneyo Evasive Action (Plane)

31

• System World What the system does within its operational environment

What are the information needed ?

What functions should be performed ?System records log of useSystem gives account BalanceSystem monitors patient

• Development World Process

Team

Schedule

Qualities (Non-Functional Requirements)System to be delivered in 12 monthsTeam should not exceed 12 people

3232

Developing a Project Schedule1. Identify individual tasks for each activity

• Top-down or bottom-up approach

2. Estimate the size of each task (time and resources) – optimistic, pessimistic and expected times

3. Determine the sequence for the tasks4. Schedule the tasks• Charting methods (Appendix C)

PERT/CPM (Project Evaluation and Review Technique/Critical Path Method) chart shows the relationships based on tasks or activities Defines tasks that can be done concurrently or not and

critical path

Gantt chart shows calendar information for each task as a bar chart Shows schedules well but not dependencies as well

3333

3434

3535

Gantt Chart• Tasks represented by vertical bars

• Vertical tick marks are calendar days and weeks

• Shows calendar information in a way that is easy

• Bars may be colored or darkened to show completed tasks

• Vertical line indicates today’s date

3636

3737

Further Preparations

• Staffing the ProjectDevelop a resource plan Identify and request technical staff Identify and request specific user staffOrganize the project team into work groupsConduct preliminary training and team-building

3838

2. Confirming Project FeasibilityEconomic feasibility – cost-benefit analysisOrganizational and cultural feasibility

E.g. low level of computer literacy, fear of employment loss

Technological feasibilityProposed technological requirements and available expertise

Schedule feasibilityHow well can do in fixed time or deadline (e.g. Y2K projects)

Resource feasibilityAvailability of team, computer resources, support staff

• Economic FeasibilityThe analysis to compare costs and benefits to see whether

the investment in the development of the system will be more beneficial than than costly

3939

• Costs

Development costs : salaries and wages, equipment and installation, software and licenses, consulting fees and payments to third parties, training, facilities, utilities and tools, support staff, travel and miscellaneous

Sources of Ongoing Costs of Operations: connectivity, equipment maintenance, computer operations, programming support, amortization of equipment, training and ongoing assistance (help desk), supplies

4040

• BenefitsTangible benefits - examples

Reducing staff (due to automation)Maintaining constant staffDecreasing operating expensesReducing error rates (due to automation)Ensuring quicker processing and turnaboutCapturing lost discountsReducing bad accounts or bad credit lossesReducing inventory or merchandise lossCollecting accounts receivable more quicklyCapturing income lost due to “stock outs”Reducing the cost of goods with volume discountsReducing paperwork costs

4141

• Benefits Intangible benefits – examples

Increased customer satisfactionSurvivalSafety of a Patient The need to develop in-house expertise

Note - also can have intangible costs for a projectreduced employee morallost productivitylost customer or sales

4242

Conducting the feasibility study

• Each category of cost is estimated• Salaries and wages are calculated based on

staffing requirements• Other costs such as equipment, software

licenses, training are also estimated• A summary of development costs and annual

operating costs is created• A summary of benefits is created• Net present value (NPV) – present value of

benefits and costs, is calculated for e.g. 5 year period

• Decision is made to proceed with project or not

4343

4444

Job Time Salary Total

Project Manager

12 months

90,000 90,000

System Analyst (3)

9 months 75,000 168,750

Programmers (6)

7 months 50,000 175,000

Network Designer

5 months 70,000 29,166

462,916

4545

4646

4747

48

49

Ok. How Elicitation fits ?• First part of Requirements Process

• But it goes throughout the whole software

• Never stops

50

• Another Definition for Requirements: An externally Observable Characteristic of a Desired System

• 2 Buttons in a mouse If the user needs 2 buttons this is a requirement

If the user only need a way of moving slides back and forth, this is too detailed to be a requirement

51

Tackling the problem not the solution

My Elevator is too slow• My Elevator is slow

•You have a throughput problem not a speed problem !

52

Tackling the problem not the solution

• Well it’s a problem because people complaint about the lines

•Why is that a problem ?

• Solution ????

• My Elevator is slow

•How better should it be?

As better as needed for stopping complaints

53

Basic Needs for Elicitation

(Questions from Polya)

• What is unknown?

• Do you know any related problem?

• Can you reinvent the problem?

54

Elicitation

Elicit [Var. elicit + make it clearer + extract]1.discover, make explicit, get as much

information as possible to understand the object being studied.

55

Elicitation

• Identify sources of information

• Gather facts

• Communication

56

Elicitation• Gathering information may be hard

Communication can be difficult (different languages and knowledge)

Stakeholder may be (often are) hard to meetThey may have conflicting objectivesStakeholder often have different viewpoints regarding the

same thingKnowledge is usually distributed among many different

sourcesThe mere presence of an outsider may change the processHidden agendasFear of change

57

Who is related to the software?

interested

customer

developers

users

clients

OwnerEspecialist

Partner

Third party clients

Investor

Quality Control (QC)Technical writers

Software Engineer

clients

Non-clients

58

Identifying Sources of Information• Actors in the Universe of Discourse

Clients Users Developers

• Documents• Books• Software Systems• COTS

59

Criteria

• Experience

• Knowledge about the domain

• Volume of investment

• What the stakeholder does daily

60

Sources of Information

UofD

UofDSource of Information = { a,b,c,d,e,f} U {g,h}

61

Heuristics to identify sources of information

• Who is the client?• Who owns the system?• Is there any customized system available?• What are the books related to the application?• Is it possible to reuse software artifacts? • What are the documents most cited by the actors of

UofD?

62

Facts gathering

• Document Reading• Observation• Interviews• Reunions • Questionnaires• Anthropology• Active participation from actors• Protocol Analysis• Reverse Engineering• Reuse

63

Tacit Knowledge

• The kind of knowledge that is trivial for the actor being interviewed but not for the interviewer

• Because it is trivial, people almost never remebers to mention it. The interviewer in his/her turn, not knowing about the tacit knowledge can not ask about it.

64

Psychological Considerations• Experts are not used to describing what they do

3 Stage model of learningCognitive – verbal rehearsal of tasksAssociative – reinforcement through repetitionAutonomous – compiled

• Representational Problems Experts don’t have the language to describe their knowledge

No verbal language are preciseRE and Users must work together to understand each other

• Brittleness Knowledge is created not extracted

Knowledge models are abstractions of reality - has to be selectiveBrittleness caused by the simplifying assumption – instead of adding more

knowledge a better (more comprehensive) model is needed

65

66

67

68

69

70