Requirements and Specification: Software Engineering 3/10

  • Article

Requirements and Specification

Creation and generation of requirements and specifications, students, unless they are working as consultants or with sales people, may have difficulty understanding how to generate requirements for a project. Undergraduate students often have had little experience with adding code to an existing project, and usually have worked on homework problems that are adapted to the learning system that require them to “do their own work”. Graduate students may have experienced team software efforts, but do not have experiences that are easily shared with other students, in some regions the graduates may be legally bound to not say anything about their workplace. In both cases, students often have difficulties with the gathering of requirements from customers.

Creation of the requirements flow from the functional specifications, which act as a structure for the overall requirements, once the project is in progress or in maintenance then the functional specifications act as a repository for the documents.

Creation of requirements and specification [i]

The Functional Specification is the repository for the set of deep, technical drill-down documents that detail every element of the solution deliverables, explaining in exact and specific terms what the team is building and deploying. The Functional Specification is the final technical document against which every development team member will build. The Functional Specification is built upon the foundation of 8 separate documents, which are summarized in the Functional Specification. You may choose to provide customers with all 9 documents (4 requirements document, 1 Usage Scenarios document, 3 design documents, plus the parent Functional Specification document), or you may simply choose to combine the requirements documents, usage scenarios, and design documents into a single Functional Specification with sub-topics. The eight foundational documents are:

Usage Scenarios [ii]

  • The Usage Scenarios document describes the set of activities that the solution will address and support. These activities are described in terms of what the user wants the solution to do and what other interfacing applications and systems need the solution to do. This information is expressed in terms of actions (functions), actors (users in a specific situation), paths (moving from one state to another within a function), conditions (what must occur to move down the path), and results (output). The Appendix contains guidelines on how to develop this information.

User Requirements [iii]

  • The User Requirements document defines the non-functional aspect of the user’s interaction with the solution. It provides guidance on the user interface, expectations of the solution’s performance, reliability, and accessibility, and defines what must be done in order to properly train the users on the solution.

Business Requirements [iv]

  • The Business Requirements document defines the needs of the organization with regards to the solution. While user requirements address individual or groups of users, operations requirements address the needs of the operating environment, and system requirements address the hardware and operating system needs, the business requirements define what the solution must deliver to capitalize on a business opportunity or to manage business challenges.

Operations Requirements [v]

  • The Operations Requirements describe what the solution must deliver to maximize operability and improve service delivery with reduced downtime and risks. It addresses the key elements of operations - reliability, availability, scalability, supportability, and manageability.

System Requirements [vi]

  • The System Requirements define the current state of the IT infrastructure (cable, routers, bridges, etc. that provide a service) and how that current state will be impacted by the new solution. It identifies how the new solution will interact with the existing system and where critical dependencies exist that must be carefully managed.

Conceptual Design [vii]

  • The Conceptual Design is a strategic statement of how the solution will provide value to the collection of usage scenarios. The usage scenarios describe all the participants and activities within a business environment that require a solution. The Conceptual Design addresses that need by describing one or more alternative solutions. This design statement is expressed in the context of the solution users (customer, external services, etc), and describes what the solution will do to support their activities.
  • Visuals make a great impact and increase readers’ understanding of the Conceptual Design. This can be accomplished using UML diagrams, Microsoft Visio diagrams, or Application and Database modeling tools, and other types of graphics.
  • The Conceptual Design document should be brief. The audience for this document is likely to include parties outside the development team who do not have deep technical knowledge. In that context, this document is a powerful communication tool.

Logical Design [viii]

  • The Logical Design presents a complete and unambiguous definition of the solution’s logical elements from the user and functional point-of-view. This design is written without the encumbrances of architecture, technology, and infrastructure. A logical design identifies and defines all the objects and their behaviors, attributes, and relationships within the scope of the solution.
  • The goal of the logical design is to convert the contents of the usage scenarios and conceptual design into an abstract model that identifies the cooperating logical components that support the solution.
  • The logical design does not identify specific technologies. The goal is to analyze and understand the solution’s functionality before making any technology commitments. If the final design includes custom components (components not provided in available solutions or products), including information about them in the logical design facilitates their translation directly into the physical design.

Physical Design [ix]

  • The Physical Design is the application of real-world physical design constraints applied to the Logical Design. This is developed by analyzing which pieces of the Logical Design already exist in components, what can be reused or modified, and what new pieces must be created.

[i] This section is taken from: MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322367

[ii] Logical Design.doc; MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322369

[iii] User Requirement.doc; MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322370

[iv] Business Requirements.doc: MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322371

[v] Operation Requirements.doc; MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322372

[vi] System Requirements.doc; MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322373

[vii] Conceptual Requirements.doc; MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322374

[viii] Logical Requirements.doc; MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322375

[ix] Physical Requirements.doc; MSF Process Template for CMMI Process Improvement - v4.1; https://go.microsoft.com/?linkid=7322376