01c - requirements specifications

8/13/2019 01c - Requirements Specifications

1/33

RequirementsSpecificationThe beginning of an

excellent software


2/33

Recall: Software Engineering

Requirements Engineering

Designing

Implementation

Testing and Verification

Implementation and Maintenance

Old INTORSE Files


3/33

Over the past terms

How did your Machine Projectsspecification look like?

Database Application

Simple Games

Algorithms

And so on


4/33

Something like this?


5/33

Usually had something like

this.


6/33

How are features described inyour machine project specs?


7/33

Heres the problem:

Gane and Sarson observed, We have noway of showingvivid tangible model of the

system to the users. Its hard for users toimagine whatthe new system is going to dofor them until it is actually in operation, bywhich time its usually too late.


8/33

What model can we use tohelp the useranddeveloper

UNDERSTAND the ff:?

The goalof the requirement

The interactionbetween the user andsystem

How to know if the requirement is done(acceptance criteria)?


9/33

Start with a SHORT story

Studentscanreserve equipment online so

that its more accessible to submit therequests.

Role of User

Goal/Task

Tangible benefit and value

of the feature

10

Priority


10/33

Describe the interaction How will the user USE the system to accomplish

the particular goal/task?1. Student views the reservation form.

2. Student provides request details like equipment, date, time, and

duration.

3. Student submits the request.

4. System validates the information provided.

5. System presents the reservation request details.

6. Student confirms the request information is accurate.

7. System provides a tracking ID for the request.

8. System sends the request to the person in charge for approval.

9. System informs the user that the request has been submitted.


11/33

Describe the interaction

Provide a context for the interaction

Precondition:Student is registered user.

Provide a way to verify that theinteraction has been completed.

Post-conditions: System saves the request.

Student is given a tracking ID. Person in chargereceives the request.


12/33

Define the AcceptanceCriteria

Think of alternatives or exceptions thatmust be checked.

Test that reservation may contain more than one equipment

with different dates and times.

Test that user is informed about incorrect or incomplete

details.

Test that only available equipment is displayed for

borrowing.

Test that request information is saved in the database.

Test that appropriate success or failure messages are

displayed.

Test that tracking ID must always be unique.


13/33

What about sample screens?

How much work will you need to showsample screen for the interaction in

previous slide? ^_^

Interface design is based onREQUIREMENTs. Sample screens may shiftthe focus on HOW instead of WHAT

the software will do.


14/33

Try it for yourself:

Write the specifications for the Approvalof Requests.

Step 1: Start with the story.

Step 2: Describe the interaction.

Step 3: Define the acceptancecriteria.


15/33

Pair Work

Re-write the requirements for Online EnglishTutoring System from last meeting.

CHALLENGE: Use only one sheet.

Front Page : User story

Front Page : Interaction

Back Page : Acceptance Criteria


16/33

That wasnt sohard was it?


17/33


18/33

What can go wrong withrequirements?


19/33

Ambiguous

How do you interpret this requirement:

User can view the weather for the next 24

hours.

Show the current

weather for the next 24

hours

Show the projected

weather for the

forthcoming 24 hours

or

What can happen if the client and developersinterpret this differently?


20/33

Ambiguous (more like Vague)

Example #2:

Shut off the pumps if the water level remains above 100

meters for 4 seconds.

Mean water level?

Median water level?

Root mean square water

level?

Minimum water level?

Software engineersassumed this!

Standardinterpretation


21/33

Ambiguous

The danger is that ambiguity often goesUNDETECTED. After all, how can you figure

out someone elses interpretation isdifferentfrom yours?

Requires special domain understanding orknowledge to detect the possible

interpretations!


22/33

Low-Value / Unnecessary

What can (and often does!) happen:

The developer can get excited with solving the

problems or meeting the needs of the clientand thinks of features (read: extra).

Developer finds that client is not using the

feature! (GASP) It does not help at all with what the user needs.

User can do what he needs without using thefeature.


23/33

Low-Value/Unnecessary

How to know if your requirement isvaluable?

It clearly solves a problem.

It supportsa business strategy.

It improvestheir tasks/work.

It meetsclients criteria.


24/33

IncompleteDetails can be both an advantage and a

disadvantage.

Pilot disengages the auto-pilot by applying enough force.

System responds by releasing controls of ailerons,elevators and rudder.

Actual Case: Aeroflot 593


25/33

Incomplete

Example #2 (Problem)

We arent making enough money from quarterly

treatments. Our technicians are completely booked, butthey spend at least three hours a day driving from job to

jobdouble the industry average. Our prices are

competitive, and our costs are in-line with the industry. We

need our technicians to perform more treatments per day.

Spot checks of a few previous schedules revealed thattravel time could be reduced by 70% if we reorganized the

treatments to minimize travel time.


26/33

IncompleteExample #2Requirement

We need software that determines the better routes for

our technicians each day. The optimal route is the onethat requires the minimum travel time between eachlocation, and between the office and the first location.Our software must generate routes that are 50% betterthan our existing process. Our dispatcher will be ableto use these routes to plan each technicians schedulefor the day. Note: The dispatcher will communicate thedaily schedule to each technician at the beginning ofeach shift.


27/33

IncompleteExample #2Analysis

We have data. Prices and costs are reasonable, butprofit is unacceptable. Technician efficiency is theidentified culprit. Weve written a softwarerequirement that should provide us with animprovement. Weve assessed the potential value(50% reduction in travel time) and validated that it isfeasible (70% reduction for manual spot-checks).Weve even established critera for testability of therequirement (50% improvement over existingprocesswe can use historical data to validate thesoftware solution).


28/33

IncompleteExample #2: Whats missing

Additional research reveals that 80% of the time, thetechnicians have to return to the office to pick up moretreatment chemicals because they didnt bring enoughwith them for the whole schedule, or they have to cancelthe last job of the day to account for drive time to returnleft-over chemicals to the office. The technicians can nottake the pesticides home with them, and try to avoid a

return trip to the office at the end of the day. If they use upall of the chemicals, they can drive directly home from thelast appointment.


29/33

Other problems

Unverifiable

Makes it difficult to communicate to the

team what they need to accomplish.

Inconsistent

Grammatically confusing

Logically inconsistent leading to conflicting

requirements

Impossible


30/33

Assignment 1: Rank theproblems according to (Pair):

Problem Impact Chance ofHappening

Detection Correction

Ambiguous

Low-Value


31/33

Assignment #2At the back: Reflection (Individual)

Based on our discussions, what are the

concerns (give the top 3) of requirementengineering?

How is this different from your initialimpression of writing softwarespecifications?

How do you find this phase? Do you likeit? Why or why not?


32/33

Project Plan

Feb. 1, 2013 (6:00pm)

Share Google Docs 1/grp (Send me an

email as well!)

Feb. 2, 2013 (9:00pm)

Project Plan Presentation Schedule (Outside

Class)


33/33

References http://www.agilemodeling.com/artifacts/user

Story.htm

http://www.extremeprogramming.org/rules/userstories.html

http://www.xpexchange.net/en/intro/userStory.html

http://services.natureserve.org/member/userS

tory.htm D. Pilone and R. Miles: Head First Software

Development.OReilly, 2008
http://www.agilemodeling.com/artifacts/userStory.htmhttp://www.agilemodeling.com/artifacts/userStory.htmhttp://www.extremeprogramming.org/rules/userstories.htmlhttp://www.extremeprogramming.org/rules/userstories.htmlhttp://www.xpexchange.net/en/intro/userStory.htmlhttp://www.xpexchange.net/en/intro/userStory.htmlhttp://services.natureserve.org/member/userStory.htmhttp://services.natureserve.org/member/userStory.htmhttp://services.natureserve.org/member/userStory.htmhttp://services.natureserve.org/member/userStory.htmhttp://www.xpexchange.net/en/intro/userStory.htmlhttp://www.xpexchange.net/en/intro/userStory.htmlhttp://www.xpexchange.net/en/intro/userStory.htmlhttp://www.extremeprogramming.org/rules/userstories.htmlhttp://www.extremeprogramming.org/rules/userstories.htmlhttp://www.extremeprogramming.org/rules/userstories.htmlhttp://www.agilemodeling.com/artifacts/userStory.htmhttp://www.agilemodeling.com/artifacts/userStory.htm

01c - requirements specifications

Documents