A Framework for Managing Requirements Specification ProcessSpecifying RequirementsBrooke’s defines a software entity as " a construct of interlocking concepts, and specifies four inherent properties that arise from the essential nature of software: complexity, conformability, changeability and invisibility". The direct consequence of this is that the software developer has to define the concepts of the system, represent them into specifications, elaborate and transform them into design, and explode them into more detailed object representations until finally the concepts are realized in the form of correct and complete code.When the developer is conceptualizing a system it is active in his mental model and fluid in character. He can change any concept by simply changing the conceptual structure to meet desired behavior. This implies that software is malleable and can be configured to any shape the developer desires.The multiple internal structures in the sub-domains of the system, their interactions, and interfaces combine in such a way as to make the software entity very complex. The developer conceptualizes the system and attempts to "record" the representations of the concepts in text and graphical form of specifications. As the problem domain becomes more complicated anticipating, visualizing, and representing the concepts, internal conditions, interactions, and interfaces of the various sub-domains and its behavior becomes a more complicated task and requires a systematic process.As the developer visualizes, conceptualizes and specifies the behavior of the system under all types of conditions in the input domain and in the environment its behavior becomes inflexible in responding to any other inputs other than those already specified at that point of time. But in real world conditions in the environment and input domain may change. The requirement specification process must accommodate this dynamics.Development of requirement specification describing the problem domain and the requirements the problem imposes on its solution is an essential prerequisite to the design and development of software system to meet customer expectations. The solution strategy lies in making the requirement specification process more formal and structured without loss of creativity so as to develop requirement specifications approaching zero defects.Requirements Specification ProcessProblem domain analysis, conceptual modeling and its crystallization in the form of requirement specification are an intense thinking activity. Structuring and defining a process for this would require consideration of the cognitive processes involved, the social-psychological factors related to people, and organisational and management factors.Humans follow a process of decomposition (both semantics and syntactic aspects of problem), iterative development, and step wise refinement to recognize a concept, model it, compare with real world object and refine it and elaborate it.Development PerspectiveThe developer first develops the conceptual constructs (use cases) of the problem domain at different levels of abstraction through breadth-first decomposition strategy (system to sub-systems, sub-system to activities, activity to actions) . The focus is on function and interaction required by the actors of the system to realize the function. Inputs to this process include domain knowledge and concept documents of the system and changes to be introduced in use cases. The conceptual constructs are then verified with real world objects for correctness. This forms the inner loop of the "Develop Conceptual Structure" process. The process takes place mostly by the thinking faculties of the developer and his interactions with the actors of the system. It is necessary to immediately record the conceptual constructs as they may fade away from the developer’s mind. This recorded information (in the form of Use Case Models) forms the conceptual representation of the problem domain.Once the conceptual construct is active in the developers mental model he has to visualize and develop activity models containing all possible conditions, interactions, interfaces, possible outcomes and responses to determine the behavior of the system . Inputs to this process include domain knowledge, use case models, and changes to be made in the use case models and activity models. The developer would verify whether each set of domain inputs when applied to the conceptual structure would produce the desired behavior. Otherwise he would change the conceptual structure and analyses the impact on the behavior. This forms the inner loop of the "Determine behavior" process. The recorded use case models and activity models are then improved till all possibilities are handled clearly and explicitly.Next the conceptual constructs and behavioral constructs of the problem domain are crystallized and represented in the form of some software artifact (a User Requirements Document). Inputs to this process include use case models, activity models, domain knowledge and changes to be made to the user requirement document. The developer verifies the completeness and correctness of the representation for improvement in the inner loop of the "Crystallize concepts and behavior" process.In the "Evaluation" process actors of the system review the software artifact to identify defects in the conceptual and behavioral representation of the system. Changes to be made are identified and introduced in the software artifact and evaluated again. This iterative process is continued till the software artifact (User Requirement Document) specifies the problem domain and the solution requirements.Within a process inner looping for iteration and refinement of the work product is allowed automatically, but needs to be recorded. Any iteration between processes for introducing changes and refining the work product is controlled.Management Perspective"Configuration management" and "Project management" processes are management processes. They manage the entire requirement specification process to ensure that dynamics of the real world are adopted easily by appropriate planning, implementation and control .Planning:A project team consisting of project management team, development team, requirement review team and configuration management team would be constituted. The development team would develop requirement specifications. The requirements review team would evaluate work products to ensure conformance to system and meet expectations of the actors. The configuration management team would configure requirements and manage changes.The project management team would tailor the generic requirement specification process to suit the project including the artifacts to be delivered, standards to be met and guidelines to be followed. Based on the tailored process definition and the scope of the system an implementation plan containing activity schedule and resource requirements is prepared.Implementation: The "Develop conceptual constructs" and "Determine behavior" processes are implemented through brain storming and facilitated exchanges of the development team and users. The "Crystallize concepts & behavior" process is implemented through rapid prototyping supported by a tool. The developer team does evaluation of work products internal to a process for conformance, defect removal, and change introduction, but these are formally recorded.The "Evaluation" process is implemented by means of formal inspection of the work products to ensure completeness and correctness. The defects identified are classified and formally recorded. The changes to be made in the work products to fix defects are identified.The "Configuration management" process is implemented by means of planning and review meetings to configure requirements and allocate them to different iteration cycles of the system development. It controls changes to be introduced in the work products due to dynamics of the system or to fix identified defects.The "Project management review" process is implemented by means of planning and review meetings. At the beginning it would review the process plan and implementation plan for development of requirement specification. A periodic meeting would be conducted to formally review the progress of the plan, schedules, requirement changes, defects, and defect correction and adequacy of the process and recommends in-process improvement action. A terminal review would be conducted at the end of each iteration cycle to ensure that requirement specification conforms to the system and meets user expectations.Control: Effective internal evaluation, formal inspection and careful change control would ensure defect free requirement specification. The cost and bureaucracy associated with inspection and change control are essential. Management control of requirement specification process is ensured through planning and review meetings.ConclusionsSoftware requirement development is a thinking activity. The software requirement specification contains only those sets of conceptual descriptions and behavior of the problem domain as in the mental model of the developer. Dynamics of the problem domain and its environment require the software system to be malleable and changeable to meet customer expectations.A generic requirement specification process has been described providing for the creative nature of this activity. The process involves development of conceptual constructs and behavioral constructs of the problem domain and its crystallization in the form of requirement specification.A management framework has been described to systematically develop software requirements by accommodating changes, eliminating defects and providing for process improvement.Detailed study of cognitive processes, group dynamics, communication processes, organisational politics, individual’s differences is essential to improve understanding of software requirement specification process.Read More on



http://arbizaa-softwareworld.blogspot.com/