SE_UNIT2 Software Requirements PDF

Software Requirements  The process of finding out, analysing, documenting and checking these services and constraints is called requirements engineering (RE). Types of requirements User requirements - high-level abstract requirements system requirements to mean the detailed descript...

Software Requirements  The process of finding out, analysing, documenting and checking these services and constraints is called requirements engineering (RE). Types of requirements User requirements - high-level abstract requirements system requirements to mean the detailed description of what the system should do.  Software Requirements divided into 1. User requirements are statements, in a natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate. 2. System requirements set out the system's functions, services and operational constraints in detail. The system requirements document (sometimes called a functional specification) should be precise. It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers. Software system requirements are classified into 3 types: Functional Non functional Domain Functional requirements These are statements of services the system should provide, how the system should! react to particular inputs and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do. Non functional requirements These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process and standards. Non-functional requirements often apply to the system as a whole. They do not usually just apply to individual system features or services Domain requirements Domain requirements are derived from the application domain of the system rather than from the specific needs of system users. They usually include specialized domain terminology or reference to domain concepts. Domain requirements are important because they often reflect fundamentals of the application domain. If these requirements are not satisfied, it may be impossible to make the system work satisfactorily. The LIBSYS system includes a number of domain requirements: Ex: There shall be a standard user interface to all databases Functional requirements of LYBSYS 1.The user shall be able to search either all of the initial set of databases or select a subset from it. 2.The system shall provide appropriate viewers for the user to read documents in the document store. 3.Every order shall be allocated a unique identifier (ORDER_id), which the user shall be able to copy to the account's permanent storage area.  Non Functional Requirements Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific functions delivered by the system. They may relate to emergent system properties such as reliability, response time and store occupancy. Alternatively, they may define constraints on the system such as the capabilities of I/O devices and the data representations used in system interfaces. Types of Non Functional requirements Types of Non Functional requirements Product Organizational External  Product Requirements These requirements specify product behavior. Examples include performance requirements on how fast the system must execute and how much memory it requires; Reliability requirements that set out the acceptable failure rate; Ex : The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.  Organizational requirements These requirements are derived from policies and procedures in the customers and developers organization. Examples include process standards that must be used; implementation requirements such as the programming language or design method used; and delivery requirements that specify when the product and its documentation are to be delivered. Ex: The system development process and deliverable documents shall conform to the process and deliverables defined in MS word 2003 only.  External requirements This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include interoperability requirements that define how the system interacts with systems in other organizations Legislative requirements that must be followed to ensure that the system operates within the law and ethical requirements. Ethical requirements are requirements placed on a system to ensure that it will be acceptable to its users and the general public. EX : The system shall not disclose any personal information about system users apart from their name and library reference number to the library staff who use the system. Metrics for specifying non-functional requirements  User Requirements The user requirements for a system should describe the functional and non-functional requirements so that they are understandable by system users without detailed technical knowledge. If you are writing user requirements, you should not use software jargon, structured notations or formal notations, or describe the requirement by describing system implementation. You should write user requirements in simple language, with simple tables and forms and intuitive diagrams. Various problems can arise when requirements are written in natural language sentences in a text document 1. Lack of clarity It is sometimes difficult to use language in a precise and unambiguous way without making the document wordy and difficult to read. 2. Requirements confusion Functional requirements, non-functional requirements, system goals and design information may not be clearly distinguished. 3. Requirements amalgamation Several different requirements may be expressed together as a single requirement.  Guidelines To minimize misunderstandings when writing user requirements Invent a standard format and ensure that all requirement definitions adhere to that format. Standardizing the format makes omissions less likely and requirements easier to check. The format I use shows the initial requirement in boldface, including a statement of rationale with each user requirement and a reference to the more detailed system requirement specification. You may also include information on who proposed the requirement (the requirement source) so that you know whom to consult if the requirement has to be changed.  Use language consistently. You should always distinguish between mandatory and desirable requirements. Mandatory requirements are requirements that the system must support and are usually written using 'shall’. Desirable requirements are not essential and are written using 'should’. Use text highlighting (bold, italic or color) to pick out key parts of the requirement. Avoid, as far as possible, the use of computer jargon. Inevitably, however, detailed technical terms will creep into the user requirements  System Requirements System requirements are expanded versions of the user requirements that are used by software engineers as the starting point for the system design. The system requirements should simply describe the external behavior of the system and its operational constraints. They should not be concerned with how the system should be designed or implemented.  The software requirements document The software requirements document (sometimes called the software requirements specification or SRS) is the official statement of what the system developers should implement. It should include both the user requirements for a system and a detailed specification of the system requirements. In some cases, the user and system requirements may be integrated into a single description. In other cases, the user requirements are defined in an introduction to the system requirements specification. If there are a large number of requirements, the detailed system requirements may be presented in a separate document The level of detail that you should include in a requirements document depends on the type of system that is being developed and the development process used. A number of large organizations, such as the US Department of Defense and the IEEE, have defined standards for requirements documents. Users of a Requirement Document This IEEE standard suggests the following structure for requirements documents: 1. Introduction 1. Purpose of the requirements document 2. Scope of the product 3. Definitions, acronyms and abbreviations 4. References 5. Overview of the remainder of the document 2. General description 1. Product perspective 2. Product functions 3. User characteristics 4. General constraints 5. Assumptions and dependencies 3.Specific requirements cover functional, non··functional and interface requirements. This is obviously the most substantial part of the document but because of the wide variability in organizational practice, it is not appropriate to define a standard structure for this section. 4. Appendices 5. Index Although the IEEE standard is not ideal, it contains a great deal of good advice on how to write requirements and how to avoid problems. It is too general to be an organizational standard in its own right. The Structure of the Requirement Document