The Process and Importance of Requirements Elicitation Specification and Documentation Robert Hinson
University of West Florida
In the world today, people are relying more and more on technology for their every day needs. Part of this reliance stems from a growing need of on the go service. People love to talk about how great their smart phone or tablet is, but what many people don’t realize is that without the software that is designed to run on these mobile devices, none of this would be possible. More and more people are using a broad variety of software types, thus the importance of software documentation has never been higher. Software documentation is defined as “program listings or technical manuals describing the operation and use of programs” (Dictionary, 2012). There are many different factors that go into software documentation, including their requirements, how software documentation requirements are documents, how they are specified, who is involved in the requirements process, and why such processes are important. A lot of times, people don’t even know what software documentation is all about. It isn’t interesting to people, and most people would just ignore it all together and delve into the software. If they run into a problem, however, then the user will read the documentation. Because of this, it is very important to make sure that your documentation is correct and easily understood by the user. Software requirements can help a user understand why a product is needed. Not all requirements are at the same level. The software requirements are statements of what the system is designed to do, not necessarily how it will be done. The process of requirements can be broken down into discovery (elicitation), analysis, modeling and documentation, communication, and validation (Schedlbauer, 2011). The requirements will also describe what the finished product will be like. The requirements should also include descriptions of the system properties, the specifications for how the system is designed to work, and constraints that were placed upon the development process. It will also usually include the project budget and staffing requirements, as well as a schedule and tools used in the development project. The system requirements are written in technical detail and describe the functions that the system will need to perform.
Unlike system requirements, the user requirements are usually written in a narrative form. These are written in the point of view of the end user. There are also interface requirements, which specify how the interface will look and behave. The interface requirements are generally illustrated and include screen captures, narratives, and lists of some sort. When trying to determine the requirements for software, the best thing to do is to start with writing out the user’s needs. You can easily accomplish this by writing down questions that the user has so that you can be sure to provide a solution for them. The requirements document will include a formal list of the requirements. You will want to be able to distribute these documents through multiple outlets, include paper and the web. Keep in mind that the user may want to access this information even if their paper documentation isn’t around. A document writer will also need to be sure to update the documentation as needed. The quality software requirements include statements that should accurately describe the functionality that is to be delivered by the software. User representatives would determine the correctness of user requirements by inspecting their accuracy. It also must be feasible to implement each requirement within the structured capabilities and limitations of the software environment. The developer should work with the requirements analysts to ensure that the requirements are not infeasible, or beyond the limitations of the software that is being documents (Wiegers, 1999). The...
References: Dictionary (2012). software documentation. Retrieved from http://dictionary.reference.com/browse/software+documentation?s=t
Heumann, J. (2004, July 14). Writing good requirements is a lot like writing good code. Retrieved from www.ibm.com/developerworks/rational/library/5170.html
Schedlbauer, Martin. (2011). The Quest for Good Requirements. Retrieved from http://www.batimes.com/articles/the-quest-for-good-requirements.html
Weisert, C. (2003, April 22). Requirements are not discrete -- nor are they "non functional". Retrieved from www.idinews.com/nonFunctional.html
Wiegers, K. (1999, May). Writing quality requirements. Retrieved from www.processimpact.com/articles/qualreqs.html
Please join StudyMode to read the full document