Expressing requirements

From SoftwarePractice.org

There are many ways of expressing requirements in software design. Although formal methods are well-established, the agile development movement has highlighted that there is in fact a spectrum of different methods, with differing levels of detail and formality.

Relevant course material

• Expressing requirements (With lecture slides)

Tutorial

In this tutorial, you will be creating some of the requirements artifacts that you will be working with throughout the semester. Since this is your first effort, we will focus on the earlier, informal methods. Your goal in the tutorial is to ensure that you understand what you need to do to make further progress with gathering and refining the requirements for your project assignment. After the tutorial, you have all you need to immediately commence the Inception phase of your project.

Important note: You have a great deal to do in this tutorial. Don't get bogged down with any stage, though. If you get stuck (for example) writing scenarios, try writing one or two essential use cases, and then go back to the scenarios to see if you understand them better.

1. Team formation. Form into the same teams as last time. If you are not yet in a team, now is the time to do it. Teams should consist of four people each.
2. Project choice. The instructor will hand out project descriptions. There will be a small number from which you can choose. Discuss amongst your team which one interests you most. At the front of the class will be a set of cards with project names on them -- write your team ID on an empty card labeled with the project of your choice. (If there are no cards with your project name on them, you will have to choose another.) Don't choose your project based on perceived level of difficulty -- they are all sufficiently challenging to keep your team busy for the whole semester!
3. Identify stakeholders. Brainstorm with your team to identify stakeholders. Consider all possible "angles," from business and market concerns, development, maintenance, system administration and deployment, and end-user needs. Label a single index card "Stakeholders" and write each stakeholder on it, along with a short list of their key concerns.
4. Write scenarios. Brainstorm with your team to identify three or four key usage scenarios. The scenarios should capture the most important aspects of the system's use. (For example, don't write four scenarios about different ways to log into the system.) Write each on an index card, and label the index card with its name.
5. Write essential use cases. Lay the scenario cards out on the table. From them, identify four to six potential use cases. (Note that uses cases often capture a "smaller" piece of interaction with a system than a scenario.) Work with your team to create essential use cases for as many as you can. Again, focus on creating a set of use cases that together capture the key functionality expected of the system. Write each essential use case on an index card. Note: don't worry too much at this point about whether you have got the use cases "right." Use them to drive your project development and modify or refine them as needed in order to make progress.
6. Draw a use-case diagram. Draw a use-case diagram that relates stakeholders to use cases.
7. Wrap-up. By the end of the tutorial, you will have index cards for:
   • Stakeholders (1)
   • Scenarios (3-4)
   • Essential use cases (4-6)
   • Use case diagram (1)
   The tutor will wrap up the class by asking some teams to walk the rest of the class through their results.
8. Follow-up. After the tutorial is over, go to the Wiki on this site and create your project documentation article. Add your best scenarios and use cases to the article.