Last User to make Changes Date Summary of Changes



Download 68.5 Kb.
Date conversion23.12.2016
Size68.5 Kb.



Revision History

Last User to make Changes

Date

Summary of Changes

L. Armstrong

7/4/2011

Initial Release









[This section is optional. Revision history may also be recorded as part of version control.]


Table of Contents



1

1

1

Vision Statement 4

Vision Statement 4

Requirements 5

Requirements 5

Step #1: Identify Categories of Users 5

Step #2: Create Actor-Goal List 5

Step #3: Identify User Stories 6

[Step #4: Write Use Cases] 8

Sprint #1 12

Sprint #1 12

Review 12

Retrospective 12

Design 14

Design 14

Coding Standards 15


Coding Standards 15



Vision Statement


The vision (or mission) statement sets the direction for the project by specifying what will be accomplished. It defines the scope of the project. The main elements of a vision statement include:

  • Project goals – Projects start with an idea to solve a problem or take advantage of an opportunity. The goals of the project should align with the problems and opportunities identified. Goals express the expected outcomes from the project. Goals should be SMART: Specific, Measurable, Action-oriented, Realistic, and Timely.

  • Project scope – What is and is not included in the project?

  • High-level features or requirements. Are some features more important than others? One way of prioritizing features is to divide them into two classes: essential and desirable.

Two useful exercises for developing a vision statement are [Agile Project Management]:

  • Pretend the software will be sold as a retail commercial product and then design the box in which the software will ship. The shrink-wrapped box for retail software lists the key features of the software from the user’s perspective.

  • Develop an elevator statement for the project. A good elevator statement answers the question “what” and “why” in a succinct and compelling way.

Here is a convenient template for developing an elevator statement for a product:

  • For (target customer)

  • Who (statement of need or opportunity)

  • The (product name) is a (product category)

  • That (key benefit, compelling reason to buy)

  • Unlike (primary competitive alternative)

  • Our product (statement of primary differentiation)

Example

For computer users of all ages who want to socialize and keep in touch with family, friends and associates, the MultiFace web site is a social networking web site that allows users to maintain multiple personas. Unlike traditional social networking web sites such as FaceBook and MySpace, our product allows users to maintain separate and distinct identifies for different groups of family, friends and associates.

A good vision statement helps you make decisions regarding priorities and what to include and what to exclude.

Requirements


Before you can build something you have to know what it is that needs building.

The vision statement sets the direction for the project but isn’t detailed enough to begin high-level planning let alone programming.

Requirements tend to evolve from the general to the more specific. At a minimum, product requirements should be specified as a prioritized list of user stories with effort estimates for each story. Effort may be specified in units of story points or ideal days/hours. Effort estimates are needed so the product owner can prioritize the stories. Accept free form voice commands might seem like a nice feature (high priority item) until the product owner realizes it will cost a small fortune to implement.

Sometimes it helps to elaborate requirements in greater detail before planning project iterations. If requirements aren’t expected to change significantly during product development and can be determined without feedback from early system increments, exploring requirements in greater detail at the start of the project is likely to lead to better estimates and more efficient plans. Detailed requirements are often specified with use cases and system shalls.


Step #1: Identify Categories of Users


A good first step towards identifying system requirements is identifying the different categories or types of users.

Example:


Volunteers – Adults with computer knowledge sufficient to navigate a web-based interface.

Step #2: Create Actor-Goal List

The actor-goal list shows the mid-level goals for each system actor. The categories of users above define human actors. In addition to human actors, there may be other non-human system actors such as external computer systems.

Probably the hardest part of creating an actor-goal list is deciding at what level of abstraction to express goals. For example, “make money” might be a goal but is too abstract to be useful as the only goal expressed in a requirements document. You can’t plan, estimate or design a software system based solely on the goal “make money”.

At the other extreme, “close dialog box” is too specific. No one is going to read a requirements document that lists goals at this level of specificity. To avoid having overly constraining goals, consider developing the goals in collaboration with the programmers that will be implementing the system.

Goals should be expressed at a level of abstraction that allows:


  • Users and customer to see what they will be getting (users and the customer need to be able to review and validate requirements)

  • The project manager to estimate the cost and schedule for the project

  • The project manager to plan the project (that is, create a course-grain release plan and fine-grain iteration plans. Release plans express a tentative schedule for delivering features, iteration plans express a detailed schedule of tasks for implementing the features of an iteration.)

The detail included here will also depend on what other sections are included in the requirements document. Some of the details of the requirements can be expressed as system shalls. If there is a section listing “system shalls”, goals here can be more abstract.

Example actor-goal list:



Actor

Goal

Quiz Taker

Find quiz in area of interest




Browse list of available quizzes




Take a quiz




Submit partial results




Review quiz result

Quiz Author

Create a quiz




Select a quiz question from bank of questions within a particular domain




Publish a quiz




Review results of quiz

Administrator

Grant authority for quiz authors to create quizzes







Notice that some of the goals in the example above include sub goals. For example, “Submit partial results” is a sub goal of a Quiz Taker’s “Take a quiz” goal. Organizing goals hierarchically is one way of expressing more detailed goals but in a way that makes them easy to review and validate.

Step #3: Identify User Stories


User stories are descriptions of desirable system features, ideally describing some customer-visible functionality.

A useful format for expressing user stories is:

As a , I want so that

The third part (so that ) is often clear from the context and doesn’t have to be explicitly stated.

For example:


As a customer of the shared rewards program, I want to be able to search for participating businesses

When following the Scrum methodology, the product owner prioritizes the product backlog items. The priorities establish the order the stories will be implemented. The desirability or priority of a story is heavily dependent on the cost. All other things being equal, you definitely want to implement a nice-to-have feature that is trivial to implement before a nice-to-have feature that is very expensive to implement. The product owner presumably can estimate the business value of a story but needs the team to estimate relative cost of implementing each story. In Scrum, this is done by estimating the effort in terms of story points.

A story point is a relative measure. Estimating the first story is easy: it can be any number of story points you want. Estimating the second story requires a little more effort. If you said the first story was 7 story points and you estimate the second story to be about half as much work, the effort estimate for the second story will be 3.5. Practically speaking, a value of 3.5 conveys a false sense of precision so you will probably want to estimate it at 3 or 4.

Here are a couple more examples of stories with story point estimates:


Allow quiz taker to save partial work

Estimated Effort: 4 Story Points

While taking a quiz, the quiz taker should be given the option of saving partial results.




Allow quiz taker to find

and subscribe to a new quiz

Estimated Effort: 17 Story Points

A quiz taker must subscribe to a quiz before he or she can take it. The quiz taker should be given a means of finding and subscribing to quizzes.

Product Backlog


The collection of stories makes up your project’s product backlog:


Story ID

Story

Story Points

Priority

Status

S1

Allow quiz taker to save partial work

4

2




S2

Allow quiz taker to find and subscribe to a new quiz

17

3




S3

As a quiz writer I would like to be able to import and export quizzes so that I can share quizzes with my colleagues.

16

1

Completed

8/3/2016


S4

Remove associate table and normalize remaining tables in database

10

4






[Step #4: Write Use Cases]


[Writing use cases this semester is option. Sometimes it’s helpful to define more detailed project requirements up front.]

Use cases describe how users will interact with the system. They are an excellent way of capturing detailed functional requirements. Use cases may be written at the beginning of the project or during the iteration in which the features they describe are implemented.

Example:

Title:

Find and subscribe to quizzes

Use case ID:

UC001

Actor:

Quiz Taker

Description:

This use case describes the system interactions needed to find and subscribe to a new quiz.

Basic Flow:


  1. This use case begins when a quiz taker elects to search for a new quiz.

  2. The system responds by showing a complete list of available quizzes. Quizzes that the quiz taker is currently subscribed to are shown but not selectable. Quizzes the user has never taken, or has taken in the past but is not currently subscribed to, are selectable. The system shows the title of available quizzes.

  3. The quiz taker selects one of the selectable quizzes.

  4. The system shows the selected quiz as selected.

  5. The quiz taker elects to exit the search function. The quiz taker is now subscribed to the selected quizzes.

Alternate Flows:

2a. There are no quizzes available.

1. The system displays a message that no quizzes are available.

3a. The quiz taker selects more than one quiz.

1. All selected quizzes are shown as selected.

3b. The quiz taker wants to unselect a quiz.

1. The quiz taker repeats the select operation on the quiz he or she wants to unselect.

2. The quiz is shown as unselected.



Exceptions:

2. There is a format error in quiz data.



  1. The quiz taker is presented with an error message identifying the quiz or quizzes that are incorrectly formatted. The error message identifies the incorrectly formatted quiz without giving away any of the data on specific questions. Service continues with data from correctly formatted quizzes.

Open issues:
  1. If there are no quizzes available, should the quiz taker be given instructions on how to gain access to quizzes? This could be useful in situations where the quiz data files have been misplaced, moved or deleted.


When documenting detailed requirements at the beginning of a project, consider using system shalls to specify requirement detail that isn’t conveniently captured by stories and use cases.

There are an incredible amount of detailed decisions that have to be made even for simple applications. For example:


  1. If a user enters a valid ID but invalid password should the system be helpful and respond that only the password was incorrect or report back a generic “logon attempt failed”?

  2. How many logon attempt failures for a valid ID are allowed before the system blocks attempts? During what timeframe?

  3. Should blocking be temporary? If so, how long is “temporary”?

That’s 5 questions that need to be answered and we haven’t even got past the login. Documenting these decisions in use case specifications will likely make them unreadable. These detailed requirements that aren’t part of the abstract or logical behavior of the system can be specified in a long list of “system shalls”.

Example:


  1. While taking a quiz, a quiz taker shall be able to save partial results.

  2. The system shall provide the quiz author the ability to create multiple choice, true/false and multiple selection questions.

  3. The system shall automatically grade multiple choice, true/false and multiple selection questions.

  4. The system shall provide the quiz author the ability to create essay questions.

  5. The system shall automatically grade essay questions.

  6. The system shall give authors the ability to create pass/fail quizzes.

  7. The system shall give the author the ability to limit the feedback given to quiz takers. (For example, the quiz author might want to prevent the quiz taker from seeing his or her score.)
  8. The system shall keep quiz answers confidential. Users should not be allowed unauthorized access to answers.

It may also be helpful to document decisions or facts from the problem domain that might be useful in specifying requirements. Doing so helps avoid repeatedly asking the customer and can avoid reopening discussions/debates. For example, here are some general business rules for a loyalty rewards program:



  1. Customer earns points on every purchase at participating merchants at a rate of 1 point per $1 spent.

  2. Points are redeemed in units of 100. Every 100 points is worth $5 off select items

  3. Merchants can decide what items can be purchased at a discount using points

  4. Customers are not allowed to earn points when redeeming points (on cash balance of transition)

If there are important non-function requirements, consider documenting them separately.

Example:

The system shall be easy to use. A representative user fitting the profile of Volunteer described above without any prior experience with the application should be able to find and subscribe to a specific quiz in less than 2 minutes.



Sprint #1


Before you can plan a sprint you need a prioritized list of user stories (the product backlog). Factors to consider when prioritizing stories include [Cohn, Agile Estimating and Planning]:

  1. Business value of feature

  2. Cost of implementation (story points or ideal days)

  3. Amount and value of new knowledge gained by developing the feature

  4. Risks resolved as a consequence of implementing the feature

Another important step in sprint planning is estimating project velocity. Project velocity is a measure of how much work is being completed each iteration (sprint). It is usually expressed using the same unit of measure used to estimate story effort (typically story points). For the first iteration, project velocity must be estimated based on past projects. After the first iteration, project velocity can be predicted based on the completed iterations.

The Sprint Backlog identifies stories planned for the sprint along with tasks necessary to complete each story.
Sprint Backlog

Story ID

Story / Task

Estimated

Hours

Actual

Hours

S3

Update Eclipse libraries

2







Design UI

3







Determine external file format

2







Code export

7







Code import

5







Write automated unit tests

2




S1

Add table to DB








Add stored procedure to DB

3







Add save button to quiz layout

1







Code save button event handler

6






Review


[Minutes/notes from feature demo (product review).]

Retrospective


What went well? What could have gone better? What lessons did you learn? What do you plan to do differently on the next iteration?

Example (from an actual student):


For this iteration, I planned to complete two stories; only one was completed. There were several reasons for this. The first and foremost … was a simple lack of good time management. I failed to take the time to plan in the beginning, and wasted almost a week in a codeandfix style of general mayhem, implementing features here and there and then trying to piece them together. Finally, I decided to scrap the whole thing and begin fresh. This time, I began with planning it out, but I had already lost a week’s development time, and was unable to complete both stories that I had planned to. In addition, I failed to correctly estimate several of the hours to complete tasks, as well as underestimating the learning curve that I faced. Lastly, I underestimated the actual number of tasks that were required to complete the stories, and therefore took on too much to complete.


You probably also want to calculate velocity for the just-completed iteration Velocity is the expected number of story points that can be completed during an iteration. For example, assume after the first iteration story 3 (16 story points) and just the first task of story 1 (4 story points) was completed. In this case your new velocity is 16 (total number of story points of completed stories). Notice you don’t get credit for partially completed stories. If you think this will misstate your progress, break large stories into smaller ones.



Project velocity: 16

[Q. Why is project velocity 16 in this example? A. You planned to complete two stories but only S3 was completed. S3 was worth 16 story points, so your velocity is 16. Note, this is a simple example. You should plan for 3 or more stories each iteration.]


Design


[What is the overall structure of the solution? What are the major modules of code? What are the dynamics of communication between these modules? The most common way of depicting this information is with static and dynamic models augmented with short narrative descriptions of design.]


Coding Standards

Coding standards improve readability. They make it easier to understand code written by others. Good coding standards also improve reliability.




The database is protected by copyright ©hestories.info 2017
send message

    Main page