Requirements Specification

The beginning of an excellent software

Recall: Software Engineering

Requirements Engineering Designing Implementation Testing and Verification Implementation and Maintenance

Old INTORSE Files

Over the past terms

How

did your Machine Projects specification look like?

Database Application Simple Games Algorithms And so on

Something like this?

Usually had something like this.

How are features described in your machine project specs?

Heres the problem:

Gane and Sarson observed, We have no way of showing vivid tangible model of the system to the users. Its hard for users to imagine what the new system is going to do for them until it is actually in operation, by which time its usually too late.

What model can we use to help the user and developer UNDERSTAND the ff:?
The

goal of the requirement The interaction between the user and system How to know if the requirement is done (acceptance criteria)?

Start with a SHORT story

Role of User Goal/Task

Students can reserve equipment online so that its more accessible to submit the requests.

10

Tangible benefit and value of the feature

Priority

Describe the interaction

How
1. 2.

will the user USE the system to accomplish the particular goal/task?

3. 4. 5. 6. 7. 8. 9.

Student views the reservation form. Student provides request details like equipment, date, time, and duration. Student submits the request. System validates the information provided. System presents the reservation request details. Student confirms the request information is accurate. System provides a tracking ID for the request. System sends the request to the person in charge for approval. System informs the user that the request has been submitted.

Describe the interaction

Provide

a context for the interaction

Precondition: Student is registered user.

Provide

a way to verify that the interaction has been completed.

Post-conditions: System saves the request. Student is given a tracking ID. Person in charge receives the request.

Define the Acceptance Criteria

Think

of alternatives or exceptions that must 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.

What about sample screens?

How

much work will you need to show sample screen for the interaction in previous slide? ^_^ Interface design is based on REQUIREMENTs. Sample screens may shift the focus on HOW instead of WHAT the software will do.

Try it for yourself:

Write

the specifications for the Approval of Requests. Step 1: Start with the story. Step 2: Describe the interaction. Step 3: Define the acceptance criteria.

Pair Work
Re-write

the requirements for Online English Tutoring System from last meeting. Use only one sheet.

CHALLENGE:

Front Page : User story Front Page : Interaction Back Page : Acceptance Criteria

That wasnt so hard was it?

What can go wrong with requirements?

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

or

Show the projected weather for the forthcoming 24 hours

What

can happen if the client and developers interpret this differently?

Ambiguous (more like Vague)

Example

#2:

Shut off the pumps if the water level remains above 100 meters for 4 seconds. Mean water level? Standard interpretation Root mean square water level?

Median water level?

Minimum water level? Software engineers assumed this!

Ambiguous
The

danger is that ambiguity often goes UNDETECTED. After all, how can you figure out someone elses interpretation is different from yours? Requires special domain understanding or knowledge to detect the possible interpretations!

Low-Value / Unnecessary
What

can (and often does!) happen:

The developer can get excited with solving the problems or meeting the needs of the client and 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 the feature.

Low-Value/Unnecessary
How

to know if your requirement is valuable?

It clearly solves a problem. It supports a business strategy. It improves their tasks/work. It meets clients criteria.

Incomplete
Details

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

Incomplete
Example #2 (Problem) We arent making enough money from quarterly treatments. Our technicians are completely booked, but they spend at least three hours a day driving from job to job double 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 that travel time could be reduced by 70% if we reorganized the treatments to minimize travel time.

Incomplete
Example #2 Requirement We need software that determines the better routes for our technicians each day. The optimal route is the one that requires the minimum travel time between each location, and between the office and the first location. Our software must generate routes that are 50% better than our existing process. Our dispatcher will be able to use these routes to plan each technicians schedule for the day. Note: The dispatcher will communicate the daily schedule to each technician at the beginning of each shift.

Incomplete
Example #2 Analysis We have data. Prices and costs are reasonable, but profit is unacceptable. Technician efficiency is the identified culprit. Weve written a software requirement that should provide us with an improvement. Weve assessed the potential value (50% reduction in travel time) and validated that it is feasible (70% reduction for manual spot-checks). Weve even established critera for testability of the requirement (50% improvement over existing process we can use historical data to validate the software solution).

Incomplete
Example #2: Whats missing Additional research reveals that 80% of the time, the technicians have to return to the office to pick up more treatment chemicals because they didnt bring enough with them for the whole schedule, or they have to cancel the last job of the day to account for drive time to return left-over chemicals to the office. The technicians can not take the pesticides home with them, and try to avoid a return trip to the office at the end of the day. If they use up all of the chemicals, they can drive directly home from the last appointment.

Other problems
Unverifiable

Makes it difficult to communicate to the team what they need to accomplish.

Grammatically confusing Logically inconsistent leading to conflicting requirements

Inconsistent

Impossible

Assignment 1: Rank the problems according to (Pair):

Problem Ambiguous Low-Value Impact Chance of Detection Happening Correction

Assignment #2
At the back: Reflection (Individual) Based on our discussions, what are the concerns (give the top 3) of requirement engineering? How is this different from your initial impression of writing software specifications? How do you find this phase? Do you like it? Why or why not?

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)

References

http://www.agilemodeling.com/artifacts/user Story.htm http://www.extremeprogramming.org/rules/u serstories.html http://www.xpexchange.net/en/intro/userStor y.html http://services.natureserve.org/member/userS tory.htm D. Pilone and R. Miles: Head First Software Development.OReilly, 2008