Questions:
1. A functional specification is not necessarily a specification to build something new. It can be used to delineate the existing. Please, explain why and give examples and supporting facts.
2. Requirements may be partitioned into those that must be met by the first release and those that are optional. Please, explain why and give examples and supporting facts.
Answers:
1) A functional specification is not necessarily a specification to build something new. It can be used to delineate the existing. Please, explain why and give examples and supporting facts.
If something new is being built, a formal document also known as a functional specification is mandatory. It details all features and specifications of that software product. It is that phase that phase during the software development process that is managed by a lead developer, sometimes also known as functional design specification (Broy, 2010).
It would not be wrong to say that a functional specification in not necessarily a specification to build something new. It can also be used to delineate the existing. The functional specification evolves as the development of the software product progresses. It is not possible to specify all the details beforehand. We cannot specify everything before the initiation of the project. Therefore we delineate the existing product using a formal specification document and try to incorporate those changes that could not be included at the time of its first release (Sannella & Tarlecki, 2012).
For example for an interactive program we cannot define all the screen formats during the requirements phase. Once the graphical user interface is accepted, we can enhance the interactivity of the product and the user. The end user documentation and the quality assurance team are responsible for this. The software constraint that was present initially because of the nature of the task to be solved or because of a special requirement of the product has now been taken care of. Therefore we say that designing a formal document is an important task of the requirement gathering phase.
2) Requirements may be partitioned into those that must be met by the first release and those that are optional. Please, explain why and give examples and supporting facts.
Right before starting off with any project, requirements for the same should be prioritized. Requirements may be partitioned into those that must be met by the first release and those that are optional. Negotiate priorities of stakeholders and then prioritize their requirements. Before the first release of the concept, we should elaborate system requirements that are defined in the requirement specification document. Based on the collective estimate developers can design, implement and test (Khan & Alawairdhi, 2013).
After the first release we check whether the product is successful or not. According to our requirements that we have gathered we check whether the product is performing the desired functionality or not. If some loop holes are present we incorporate those requirements that we had put under optional category. Try detecting conflicting aspects and negotiate to resolve them and ensure that nothing is forgotten (Zschaler, 2009).
Say for example there is an organisation that is working on a product called xyz. The product deals with analysing customer travel requirements and thus ensuring their satisfaction. The organisation made a requirement check and once they were satisfied with the product they released its first version. The product was a success but it was getting crashed each time the number of users increased. Once they came to know their product was being appreciated by the public, they increased the peak load capacity kept under optional requirements. They then launched xyz’s second release version 2. It was a success again and thus it clearly showed that it is advisable to categorise the requirements into those that must be met by the first release and those that are optional.
References
Sannella, D., & Tarlecki, A. (2012). Foundations of algebraic specification and formal software development. Berlin: Springer.
Broy, M. (2010). Multifunctional software systems: Structured modeling and specification of functional requirements. Science Of Computer Programming, 75(12), 1193-1214. http://dx.doi.org/10.1016/j.scico.2010.06.007
Zschaler, S. (2009). Formal specification of non-functional properties of component-based software systems. Softw Syst Model, 9(2), 161-201. http://dx.doi.org/10.1007/s10270-009-0115-6
Khan, E., & Alawairdhi, M. (2013). Intelligent Agent Based Mapping of Software Requirement Specification to Design Model. JSEA, 06(12), 630-637. http://dx.doi.org/10.4236/jsea.2013.612075
