Review of the 8th chapter
This chapter is about requirements and the importance of knowing perfectly what the project need to fulfil its creation so this part is essential to the success of it.
The development of requirements is divided in three parts:
· Candidate requirements, this is done by interviewing the client questions to make sure that him and you are in the same page.
· Specifying requirements this is done by committing the candidate requirements to a tangible media, and not just words, because writing in paper make those things clear in your head, you must check and make him sign what you talked and write is what the client wants.
· Analyze requirements is breaking down the essential characteristics
When the author said, “I use the word development to emphasize that requirements work is usually not as simple as writing down what key users want the software to do.” Is brilliant, because this is a step that many people that is new in developing software skip and they just write and write what the client says and that’s not the correct way, you must analyze and say to the client if his idea will work and how you will implement it so he knows what can be done.
SPECIFYING requirements is so important for further development and specially in coding, because you will take 50-200 of time correcting the requirements, so please, make sure that your requirements are ready to be code.
The author give us nine steps to develop requirements that I would break down in an easy way.
1. Identify a set of users who will provide the guide lines in the project’s software requirements define.
2. Interview the client to create the preliminary requirements, this is the first part of the development of requirements.
3. Build a simple User Interface Prototype, prototype as simple as possible, the point of this is to present many alternatives to the user before you commit a greater effort to it.
4. Show the simple User Interface Prototype to the client and solicit his feedback. Continue revising the simple prototype, keeping it simple, showing it, and revising it again until the client is excited about the software concept.
5. Develop a guide that codifies the prototype's look and feel, review it, and put it under change control.
6. Fully extend the prototype until it demonstrates every functional area of the software. It should demonstrate the functional area, not actually implement it.
7. Put the prototype under change control. Then require the developed software to match the prototype exactly except for changes approved through the change control process.
8. Write the detailed documentation based on the prototype. This detailed documentation will become the detailed software specification, and it should also be put under change control.
9. Create separate, non-user-interface requirements document this is for the interactions with other hardware and software. Put that document under change control.
In conclusion, requirements are the base of an easy coding part so please take the time to be completely sure that the project is under these steps so you won’t fight against common errors.