Java™ Application Development on Linux - Dator

11.7 Documenting, Prototyping, and Stakeholder Buy-In273Some organizations are very formal in their understanding of requirements.They will have company-standard formats which you must follow. But thereis no magic format that will make for good requirements. It really all comesdown 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 inabsolute 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 “remainingdollars”?• 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 andterminal interaction.Not all requirements will be easily forthcoming; not all can be traced backto an exact quote from the previous discussion. Other requirements will needto be inferred from the discussion or from department “culture,” or come fromyour own judgment:• Platform: “any” PC in Ellen’s department—but her developers are all usingLinux 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.