Requirements Checklist

1.3
Updates:

none

CSC394 / IS376 Capstone Project
Requirements presentation

Elliott

Overview

In its simplest form, a requirements document is the contract between a developer and the client. It presents in a formal way what the developers expect to produce, and what the client expects to get. In a perfect world all such questions and disputes are completely answered, without discussion, by the requirements document. You will five a Lecture-style presentation of this contract between you and your clients this quarter, and also provide a formal write-up of your requirments development and testing as part of your project manual. What is the structured list of requirements you have this quarter? How will we know that you met those requirements?

How careful should you be about your requirements? Suppose that you gave these requirements to a design/implementation team that wanted to do as little as possible, and had no interest in you or your goals—they felt bound by the contract you gave them (the requirements), but would certainly look for the easy way out through any loophole in the requirements document. Now, how clearly have you compelled them to build, and test, the system you desire? This is the measure of your work, and will be the yardstick by which it is judged.

Conversely, suppose that a client was taken over by an unscrupulous corporation, and they wanted to avoid paying your development team anything. They will follow the letter of the requirements contract, but that is all. How carefully does the requirements document specify what tests you have passed so that you can prove you should be paid?

Requirements development: Are your requirements concreted, grounded, and empirically testable? If not, edit them.

Requirements tests: Given your requirements, how will you know if you met them? What explicit tests can you run for each requirement?

State diagram for the system: What are the allowable states for your system, and what are the transition triggers for the different states? See the Finite State Machine example. (You may also wish to include this technique in your design documentation.)

Note: Students tend to focus on the less-interesting, and less-demanding, aspects of screen interface and input specification. These are important, but it is often the internal workings of the system that are in much greater need of formal specification, which often have to do with the state transitions that are allowed or disallowed. Avoid spending valuable time with uniteresting screen interface discussion.

Requirements Development Process

In discussion with the user, define the problem to be solved.
Develop a framework for the organized collecting of different categories of requirements, and a hirearchical set of subrequirements, along with matching tests for each. [Categories inlcude e.g., Functional (what the system does), System (how the system is implemented), External interface (connection points to the rest of the world), State/Mode (transitions between states), Evironmental (how robust the system is and isolated from environmental effects), and performance (how effectively, how fast,... the system responds).] Thus each requirement appears in a two-dimensional matrix with a row for each requirement, and a series of columns of tests that the requirement must pass to be satisfied.
Propose a set of concrete requirements that, within the framework, when met, solve the problem.
Include a category of requirements for the group: plan, design, problem solving strategy in place, etc.
Include a category for liason with the client. What do you require be in place for successful communication with the client?
For each requirement, go through repetitive a review/editign cycle [by group members] until each requirement is considered sufficiently concrete and descriptive. A requirement is not complete until a group member has actively taken responsibility for it by explicitly signing off. Keep the development history for each requirement (think of a cell in the two-dimensional requirements matrix with a linked list of revisions stretching into the background).
Requirements may be challenged later, so we prepare by attacking them now during the development phase. For this we attacks from both sides: (a) the badly behaved client attacking a poorly formed requirement claiming it was not achieved, and (b) the badly behaved developer attacking a poorly formed requirement claiming it was achieved when it clearly does not meet the client's needs. You will need a bad-client and bad-dev attack for each requirement, or a name stating there is none to be had.

Requirements Matrix example

Number	Revision	Requirement Description	Bad-client attack	Bad-dev attack	Approved?	Sign-off name
...	...	...	...	...	...	...
10.2.3	5.0	Department Six users will rate module 12 at the 85% favorable usability level on rating document 10.2A	Better to have impartial reviewers, I can stack the deck to get poor ratings	Users may not know what it is supposed to be doing; interface just looks nice	NO	NOT APPROVED Joseph Starkman 9/15/2021
10.2.3	5.1	Independent reviewers representing Department Six will rate module 12 at the 85% favorable usability level on rating document 10.2A	OK. Passes the Bad-client attack	Interface is improved but users still may not know what the capabilities are available from this interface page; interface still looks nice, but is not fully usable	NO	NOT APPROVED Nora Smith 9/20/2021
10.2.3	5.2	Independent reviewers representing Department Six will rate module 12.1 at the 85% favorable usability level on rating document 10.2A	OK. Passes the Bad-client attack	OK. Passes the Bad-dev attack	YES	APPROVED Joseph Starkman 9/24/2021
...	...	...	...	...	...	...

Requirements Test Matrix example

Requirement Number	Test Revision	Requirements Test	Results	Pass?	Date of test	Comments	Client Sign-off name
...	...	...	...	...	...	...
10.2.3	1.0	Test 13.6: Eight users from Department Six, spent an hour going over the system. Then they rated the usability of Module 12.1 using revised rating document 10.5B.	Eight users completed the exercise and rating. They reported that they "liked the old system." Module 12.1 was rated favorable at 50%.	No	9/28/2021	Testing procedures were flawed	Not submitted
10.2.3	2.0	Test 13.6: Six users from Department Six, and Six impartial users from accounting spent two hours in the morning solving ten difficult tasks with Module 12. The next morning they spent two additional hours on solvling five more prolems. In the afternoont they rated the usability of Module 12 using revised rating document 10.5C.	Eleven users completed the tasks and rating. Three users provided comments suggesting improvements. Module 12 was rated favorable at 83%	Conditional Yes	10/01/2021	OK to pass with promise of response to user comments	Reviewed OK Martha Grimm, CTO 10/15/2021
...	...	...	...	...	...	...

Requirements presentation format

Give an overview of your full set of requirements to give us the scope of the work you have done
Give the flavor of how individual requirements are specified to show us the quality of your work
Give an overview of your full requirements test suite
Give us the flavor of how individual tests are specified to show us the quality of your testing design
Show how the requirements are matched with the tests (test matrix?). It may be true that one process completes, or partially completes the testing of more than one requirement.
Show us how tests are repeated as needed, with failures and success recorded.
Pick several interesting requirements, and show exactly how you will test or have tested for their satisfaction.
Discuss the formal schedule for the Bad Client review work. Who, dates, revisions, responses. That is, how might an unscrupulous client manipulate this requirement might when they don't want to pay?
Discuss the formal schedule for the Bad Dev review work. Who, dates, revisions, responses. That is, how might an unscrupulous developer manipulate this requirement so they can claim the requirement has been met, when clearly it does not meet the client's needs?
Discuss the work of the requirements editor. Show example history of revisions based on, e.g., the work of the Bad Client and Bad Dev .
For your final presentation (that is, at the time of your final demo), use hot links from your individual requirements to the test results, or some other mechanism, so that we can see the results of final testing for any requirement:
1. You pick an interesting requirement that recommends the group. Take us through the revisions based on the Bad Client and Bad Dev critiques. Show us the final form. Then, take us to the testing and singing off on the requirement for the finished system.
2. Now, for ANY requriement in the group (within constraints) let US pick a requirement, and do the same.
This scheme shows off your group, and then let's us believe that your high-quality work is avaiable throughout the project.
Show a state diagram for at least part of your system. What are the various states in which your system is allowed to exist? What are the transitions?
List the stakeholders for your system (entities that have a stake in the outcome of the proceeses you have modeled). For example, a stakeholder might be a provider corporation, or a corporate client.
List non-stakeholders that interact with your system. These are people or entities that interact with your system though you do not formally care about their needs. For example you might decide that you require a systems programmer, paid to keep the operating system and support software running, but from a systems point of view you are not formally concerned about what they may need to do their job.
One week after the in-class RDP presentation, at the beginning of the class session, turn in a printed form of a requirements working document. This is formal, but don't waste time making it polished at this point. It is understood that system testing won't have been completed.
Turn in your formal, finished requirements document as part of your project booklet after the full project demo is complete.

CSC394 / IS376 Capstone Project Requirements presentation