Prepare a 3-5 page requirements document for the system development selected in Week Two.
A Requirements Document is a compilation of all needs for the development of the system. It is a report that quantifies “What” the project is to accomplish and “Why” it is important with respect to overall business needs. It is reflection of your business needs – that is — what needs to be accomplished to make your business more successful. It does not address the “how”, “who” or the “when” components of the project. Those questions will be addressed once the “what” is firmly understood. The requirements are implementation neutral — there is no attempt to fit your business to a technology – but rather it is the first step in molding and fitting technology to your overall business goals.
Most business requirements are “functional” requirements, which describe the functions the system or process is to perform. Please include all four of these types in your IA paper:
Functional requirements (what must the system do). This should be your biggest section. Example:
1.1 The system will allow the user to log on using a secure password
1.2 The system shall allow the user to enter an order
1.3 The system shall allow internal marketing department employees to do an ad hoc search on individual orders, and on orders by location within a date range, and print the results
etc. etc…
Performance requirements (how fast, how many users or transactions, how much information, etc.)
Reliability and availability requirements (how much of the time should the system be working, what is the cost of downtime, etc.)
Usability requirements (must information be available in the field, does the system have to support multiple languages such as Spanish and English, how skilled or unskilled will the users be, etc.)
The “what” component
By answering “what” a project is to accomplish, it serves as the scope (that is – how big or small) and as a yardstick to judge the overall success by determining how well these requirements were fulfilled. These requirements are then used to keep projects focused on the real business necessities and to force closure on projects once that business needs have been reached. Once these requirements have been agreed upon, any change of scope should be officially approved and any necessary changes made to the implementation plan. This helps prevent “specification creep” – where more and more requirements are added until the project is completely out of control!
The “why” component
Any project will have a number of requirements that fall into the “must have” versus the “nice to have” category. By having the business needs drive the requirements, you will understand how leveraging each requirement is in reaching your overall business goals. Requirements essential to the project’s success will be quickly identified and appropriate resources can be focused on their successful implementation (STS).
Hints:
Please clearly number the requirements, so that they can be used easier later for testing. Example: Functional Requirements – 1.1, 1.2, etc. ; Performance Requirements 2.1, 2.2, 2.3, etc. and so on. Make your requirements document clear and the requirements easy to measure and test from later.
