01c - requirements specifications
TRANSCRIPT
-
8/13/2019 01c - Requirements Specifications
1/33
RequirementsSpecificationThe beginning of an
excellent software
-
8/13/2019 01c - Requirements Specifications
2/33
Recall: Software Engineering
Requirements Engineering
Designing
Implementation
Testing and Verification
Implementation and Maintenance
Old INTORSE Files
-
8/13/2019 01c - Requirements Specifications
3/33
Over the past terms
How did your Machine Projectsspecification look like?
Database Application
Simple Games
Algorithms
And so on
-
8/13/2019 01c - Requirements Specifications
4/33
Something like this?
-
8/13/2019 01c - Requirements Specifications
5/33
Usually had something like
this.
-
8/13/2019 01c - Requirements Specifications
6/33
How are features described inyour machine project specs?
-
8/13/2019 01c - Requirements Specifications
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/13/2019 01c - Requirements Specifications
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)?
-
8/13/2019 01c - Requirements Specifications
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
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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
-
8/13/2019 01c - Requirements Specifications
16/33
That wasnt sohard was it?
-
8/13/2019 01c - Requirements Specifications
17/33
-
8/13/2019 01c - Requirements Specifications
18/33
What can go wrong withrequirements?
-
8/13/2019 01c - Requirements Specifications
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?
-
8/13/2019 01c - Requirements Specifications
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
-
8/13/2019 01c - Requirements Specifications
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!
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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).
-
8/13/2019 01c - Requirements Specifications
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.
-
8/13/2019 01c - Requirements Specifications
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
-
8/13/2019 01c - Requirements Specifications
30/33
Assignment 1: Rank theproblems according to (Pair):
Problem Impact Chance ofHappening
Detection Correction
Ambiguous
Low-Value
-
8/13/2019 01c - Requirements Specifications
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?
-
8/13/2019 01c - Requirements Specifications
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)
-
8/13/2019 01c - Requirements Specifications
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