Software Requirement Documents are comprised of these key elements:
Business Drivers – describes the reasons why we need a “system”.
Building systems for streamlining business will provide ROI on software development. clearly When we clearly identify the business reasons for the system it will help us drive the right direction to achieve the goals. The drivers may be problems and opportunities for new business.
Business Model – attaining profitability is driven by a sustainable business model. This includes organizational structures, current and future diagrams, business rules, business functions and operational flow diagrams.
Functional and System Requirements – This is a hierarchical organization of requirements, with highest level functional requirements and the detailed requirements organized under each section. These requirements state the realm System abilities.
Use Cases – Typically consists of a UML use case diagram illustrating the main entities and how they will interact with the system under various use cases. For each use-case there is a definition of the steps that need to be carried out. This should be accompanied with necessary pre-conditions and post-conditions. There are two types of use cases, business and system. Business use cases are determined from the functional requirements.
System use cases are usually derived from the system requirements.
Technical Requirements – This is a list of the “non-functional” requirements. Those deal with the technical environment and operating system. These include the technical constraints and potential limitation. These are critical to determine how the higher-level functional requirements will break down into the specific system requirements.
System Qualities – These items are considered the intangible traits. They included: reliability, availability, serviceability, security, scalability, maintainability.
Constraints and Assumptions – These define any design constraints imposed by system owner. This removes options from being considered by the developers. Assumptions that are made by the requirements should be review thoroughly. Any assumptions that are turn out false will need to be re-evaluated.
Acceptance – This is the criteria that describes “sign-off” on the final system. This will be dependent on the methodology for testing and quality assurance. Agile methodology provides for acceptance at the end of each phase or iteration. The usually outlines a plan for all user acceptance tests and steps for addressing the changes for defects/bugs.