Process and Importance of Requirements Elicitation
The Process and Importance of Requirements Elicitation Specification and Documentation
Robert Hinson
CIS 3512
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
Robert Hinson
CIS 3512
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
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