UNIT 1 INTRODUCTION TO SOFTWARE REQUIREMENTS SPECIFICATION (SRS) Flashcards
What is Software Requirements Specification?
Software requirements specification documents the external requirements placed on a software system. Building on the outcome of the requirements engineering (RE) process, which defines, documents, verifies, and coordinates the conceptual requirements, SRS produces highly technical documentation of the system being designed.
How do SRS and RE differ?
In this course, the term “requirements engineering” is used to refer to the activities, methods, and techniques for identifying, documenting, verifying, and coordinating the conceptual requirements, while SRS refers to the documentation of detailed technical requirements. SRS builds on requirements engineering and documents the requirements in greater depth. The investigative techniques and testing methods used are the same for both RE and SRS. RE focuses primarily on the situation-dependent selection and application of investigative, documentation, and testing techniques for conceptual requirements. Against this background of stable conceptual requirements and prompted by the need for precise technical specifications, the focus then shifts to finding the most suitable techniques for specifying selected conceptual and technical
requirements. The RE requirements are elaborated upon and refined at a technical level until they are sufficiently detailed to allow the development team to begin its design work.
How does SRS influence the software progress?
During the SRS process, the identified conceptual requirements are elaborated upon and refined to include technical requirements. The resultant conceptual/technical specification serves as the basis for designing and later implementing the system. The specification is also used to prepare test cases for testing the software system at various levels to ensure compliance with the requirements.
Since the specification forms the basis for system design and implementation, as well as test cases, any errors in the specification or misunderstandings can have wide-ranging
implications for the entire project. Software engineering offers a wide selection of visualization techniques and tools (such as modeling tools) for defining the specific elements of
a software system and ensuring that the requirements are clearly and measurably specified.
How does SRS influence the internal design of the system?
It doesn’t. From a conceptual perspective, the system specification provides a detailed technical framework for design decisions. It is important to understand that no decisions about the internal design of the system are made in the SRS; it merely describes those system properties which are externally visible. From an SRS perspective, you could say that the system is a black box with an unknown internal structure.
Which UML use case diagram elements help identify the required specification elements?
- The system boundary: it marks out the design zone. All elements outside of these system boundaries will normally be outside the project’s sphere of influence. All use cases within the system are relevant to the specification. Defined conceptual and technical operations within a use case, as well as the required rules, business objects, and system components, must all be included in the specification.
- Communication relationships: those between human actors and the system usually take the form of a graphical user interface (GUI). If the actor is another system, a technical system interface is needed to enable the two systems to communicate with one another. Furthermore, each point where a communication relationship intersects with the system boundary requires an in-depth specification of the system interface.
- Frameworks: Where other legal, technical and organizational Framework conditions apply in the system context, these must be carefully scrutinized to ascertain their specific influence on the system. Alongside functional requirements, Framework conditions often include quality features that must be elaborated upon to form measurable quality requirements of the system during the specification process.
In a given project situation, therefore, denoting the system context as a UML use case diagram allows us to identify and model the key elements of the specification.
What are the Elements for Specifying a System’s Behavior via UML Use Case Diagrams?
The purpose of SRS is to identify and define the conceptual system elements needed to satisfy the requirements highlighted by the use case. It assigns specific business functions to each conceptual system element and specifies their behavior in detail. Elements for specifying a system’s behavior include the following:
* data model. A data model denotes the business objects processed by the system components and their relationships to one another (e.g., filing a claim, an insurance application, or client data).
* specialist functions. This is a functional description of the tasks performed by the system or specified component (e.g., algorithm for calculating premiums, cancelation procedure, or signing a contract).
* business rules. Business rules relate to a business object and must not be violated (e.g., the contract start date must precede the contract end date, or the sum total of the online shopping cart cannot be negative).
What are the elements that are necessary for the Specification of Graphical User Interfaces (GUI)?
The specification of GUIs helps the development team to design a GUI that is precisely tailored to the stakeholders’ needs. It should also enable the test team to design and implement actual test cases for the GUI. Specification of a GUI typically includes the following elements:
* content and structure of individual dialog boxes (details concerning the type, size, position, color, and content of elements on a screen page, such as input fields, texts, buttons, and images.)
* data conversion and validation (specification of rules for checking input fields for technical plausibility)
* dialog flow (Specification of user prompting through the interface depending on the user’s data entries and actions)
What are the elements that are necessary for the Specification of Technical System Interfaces?
As well as system interfaces to human users, there are also system interfaces to other information technology (IT) systems. As the system being designed will communicate externally via technical interfaces rather than via GUIs, these technical interfaces must also be specified. The following characteristics of interfaces may be defined:
* purpose of the interface on a conceptual level (e.g., transfer share prices into the fund management system, and validate address data)
* the detailed response/technical communications protocol and rules used by the system to communicate with its environment (e.g., Hypertext Transfer Protocol [HTTP], File Transer Protocol [FTP])
* the data structure of messages exchanged at the interface (e.g., Extensible Markup Language [XML], comma-separated values [CSV])
What are Software Quality Requirements and why is specifying them so important?
The SRS defines the quality standards required for the system. The standard ISO/IEC defines the term “Software Quality” as “the capability of a software product to satisfy stated and implied needs when used under specified conditions”. “Good usability,” permanent “data protection,” or “constant” availability of the system are often prescribed as required quality characteristics.
When preparing a detailed specification of quality requirements, measurable quality criteria are derived from the general requirements outlined above. These precisely formulated quality requirements will have a major influence on the system’s architecture. These types of quality requirements tend to have a far greater influence on technical implementation than adding individual functions to the functional scope.
The testability of quality criteria is also a key consideration. We have already learned that the SRS is used to prepare precise test cases. Quality requirements must therefore be defined in a way that enables their compliance to be tested.
Does the Specification Document have a standard structure?
Like conceptual requirement documents, there is no generally accepted structure for detailed specification documents. The format is governed by the system type, the individual system elements being specified, the framework conditions of the project, and the guidelines and requirements of participating companies. While the document structure in requirements engineering tends to focus more on the early phases of the software process, SRS instead documents the required system properties in depth from a conceptual/technical perspective.
What are the possible sub-headings of the specification document?
- Meta-information about the document: The meta-information contains all the data needed to make the document usable and readable. Metadata do not contain any information about the system itself, but they help
guide the reader through the document and include the document’s current status and contributing individuals. - Introduction: sets out the project’s objectives and provides a very high-level overview so that the system can be positioned within the context of the organization’s application landscape.
- System overview: is equivalent to the refined overview level in the conceptual requirements document. It provides readers with an overview of the system’s principal functions, technical interfaces, users, and positioning within the system landscape. Unlike the conceptual requirements, it may also include documentation about the system’s technical embedding in the application landscape.
- Conceptual system components (and technical components, if known): contains detailed information about the system and its interfaces. Specific functions and interfaces are assigned to system components. It may also define conceptual and technical system components and their interfaces, depending on the specific project and current level of knowledge.
- Rules that must be observed (compliance): includes all relevant guidelines and regulations that must be observed during preparation and use of the system. Requirements placed on the system or its environment are often derived from these rules, which include both statutory regulations and in-house requirements.
- Appendix: at the end of the specification generally contains more in-depth information and technical documents in summarized form for clarity and readability. This information does not directly form part of the SRS, but is intended to aid comprehension or has been extracted from the main body of the text for clarity.
What UML models are best for different applications?
- Activity diagrams and state diagrams can be used to model operations. Possible system responses can be depicted in a universal fashion. Potential applications include the specification of GUIs, technical system interfaces, and operations within a system or component.
- Class diagrams can be used to specify the conceptual
data model and business rules. - The UML object diagram is used to denote a particular data record based on the structure prescribed in a class diagram.
- The sequence diagram (and an object diagram) can also be used to denote and illustrate facts using examples.
- Use case diagrams provide a system overview and identify individual system elements for specification. Other documentation formats used in specification include GUI prototypes for the specification of user interfaces, XML languages for the specification of data structures at technical system interfaces, decision tables for the specification of system behavior, and business rules used for the specification of data structures and system behaviors, depending on the situation.
While activity diagrams (ACD) and class diagrams (CLD) are used for type-level modeling and therefore provide a general description of behavior (ACD) and structure (CLD), sequence and object diagrams are used for instance-level modeling. An object diagram is a defined version of a class diagram, while a sequence diagram is a version of an activity diagram.
