< Zurück | Inhalt | Weiter >

11.7.1 Documenting

After such a conversation, it’s smart to try to get your thoughts down on paper as soon as possible. Some of what gets said will fade with time, so work quickly to capture what you can of the requirements that were spoken. Even if you have to leave lots of blanks, keep moving and get as much of the major requirements written down as you can, even if they don’t sound very formal or polished. Then go back, revise and edit your statements, filling in the blanks where you can. Sometimes you will need to ask others to get the answers to fill in the blanks. Other times you can use your own judgment and initiative to provide an answer. Out of this process with its subsequent rewrites will come the requirements document.


Some organizations are very formal in their understanding of requirements. They will have company-standard formats which you must follow. But there is no magic format that will make for good requirements. It really all comes down to content.

Here’s an informal list of the requirements for the budget application, based on the conversation between Bob and Ellen.

Features:

• Starts with a single lump sum of dollars.

• How does this first sum get entered?

• Each dollar amount is associated with an “account.”

• Any account may be divided into two or more subaccounts.

• The dollar amount associated with a subaccount is specified either in absolute dollars or as a percentage.

• What if they don’t add up?

• Can the user mix $ and %?

• Can the user leave the last subaccount’s amount blank for “remaining dollars”?

• Tracking of the dollars—not enough info, so not in first prototype.

• Multiple users will have access to the data.

• Concurrent use is allowed and supported.

• Short development time, limited resources.

• Has a graphical user interface; earliest versions may be command-line and terminal interaction.

Not all requirements will be easily forthcoming; not all can be traced back to an exact quote from the previous discussion. Other requirements will need to be inferred from the discussion or from department “culture,” or come from your own judgment:

• Platform: “any” PC in Ellen’s department—but her developers are all using Linux platforms.

• Future platforms: “any” PC in the company means any Windows, Linux, or Mac OS X.

• Reliability: once entered, data is never lost.

• Maintainability: the application must be easy to maintain.


• Interoperability: there’s no requirement to interoperate with any other software but here’s an idea for a future version: export/import into CSV format for spreadsheets, and/or XML format for future expansion).

• Response time: “reasonable” interactive speed; subsecond response when entering new accounts and values, so that the user can type quickly and continuously; waiting, if it occurs, should only be at button presses, not between data entries.