See Our team
Wondering how we keep quality?
Got unsolved questions? Ask Questions
SE NOTES OF 3 UNIT
Software Engineering - Notes (Compiled by Vadiraja Acharya, based on Ian Sommervilleís ďSoftware EngineeringĒ 8th Ed.) Requirements Ė Unit 3 Software Requirements The requirements for a system are the descriptions of the services provided by the system and its operational constraints. These requirements reflect the needs of customers for a system that helps solve some problem such as controlling a device, placing an order or finding information. The process of finding out, analysing, documenting and checking these services and constraints is called requirements engineering (RE). If a company wishes to let a contract for a large software development project, It must define its needs in a sufficiently abstract way that a solution is not predefined. The requirements must be written so that contractors can bid for the contract, offering, different ways of meeting the clientís needs. The contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system. User requirements and system requirements may be defined as follows: 1. User requirements are a. Statements in natural language b. Diagrams of what services the system is expected to provide c. The constraints under which it must operate. 2. System requirements a. Set out the systemís functions, services and operational constraints in detail. b. The system requirements document (functional specification) should be precise. c. It should define exactly what is to be implemented. d. It may be part of the contract between the system buyer and the software developers. User and system requirements Readers of different types of specification The readers of the user requirements are o not usually concerned with how the system will be implemented and o managers who are not interested in the detailed facilities of the system. The readers of the system requirements o need to know more precisely what the system will do because they are concerned with how it will support the business processes. Functional requirements The functional requirements for a system describe what the system should do. These requirements depend on o the type of software being developed, o the expected users of the software and o the general approach taken by the organisation when writing requirements. User requirements are usually described in a fairly abstract way. Functional system requirements describe the system function in detail, its inputs and outputs, exceptions, and so on. These functional user requirements define specific facilities to be provided by the system. These have been taken from the user requirements document, and they illustrate that functional requirements may be written at different levels of detail. Imprecision in the requirements specification is the cause of many software engineering problems. In principle, the functional requirements specification of a system should be both complete and consistent. Completeness means that all services required by the user should be defined. Consistency means that requirements should not have contradictory definitions. It is easy to make mistakes and omissions when writing specifications for large, complex systems. Example: Library System Non-functional requirements Non-functional requirements 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. They specify system performance, security, availability, and other emergent properties. This means that they are often more critical than individual functional requirements. Failing to meet a non-functional requirement can mean that the whole system is unusable. Non-functional requirements such as safety and security requirements are particularly important for critical systems. Non-functional requirements may constrain the process that should be used to develop the system. Examples: quality standards that should be used in the process The types of non-functional requirements are: 1. Product requirements a. These requirements specify product behaviour. b. Examples include performance requirements on i. how fast the system must execute ii. how much memory it requires; iii. reliability requirements that set out the acceptable failure rate; iv. portability requirements; v. usability requirements. 2. Organisational requirements a. These requirements are derived from policies and procedures in the customerís and developerís organisation. b. Examples include i. Process standards that must be used; ii. Implementation requirements such as the programming language or design method used; iii. Delivery requirements that specify when the product and its documentation are to be delivered. 3. External requirements a. All requirements that are derived from factors external to the system and its development process. b. These may include i. interoperability requirements that define how the system interacts with systems in other organisations; ii. legislative requirements that must be followed to ensure that the system operates within the law; iii. Ehical requirements. A common problem with non-functional requirements is o that they can be difficult to verify. o Requirements are stated as general goals such as ease of use, the ability of the system to recover from failure or rapid user response. Non-functional requirements should be stated quantitatively so that they can be objectively tested. A number of possible metrics that you can use to specify non-functional system properties Speed o Processed transactions/second o User/Event response time o Screen refresh time Size o K bytes o Number of RAM chips Ease of use o Training time o Number of help frames Reliability o Mean time to failure o Probability of unavailability o Rate of failure occurrence o Availability Robustness o Time to restart after failure o Percentage of events causing failure o Probability of data corruption on failure Portability o Percentage of target-dependent statements o Number of target systems Domain requirements Domain requirements are o Derived from the application domain of the system. o They include specialized domain terminology or reference to domain concepts. o They may be new functional requirements in their own right. Domain requirements are important because they often reflect fundamentals of the application domain. Example: o The LIBSYS system includes a number of domain requirements: Standard based UI design. Because of copyright restrictions, some documents must be deleted immediately on arrival. o They are written in the language of the application domain (mathematical equations in this case), o It is often difficult for software engineers to understand them. o Domain experts may leave information out of a requirement simply because it is so obvious to them. o If not stated, requirements may be implemented in a wrong way. User requirements The user requirements for a system should o describe the functional and nonfunctional requirements so that they are understandable by system users without detailed technical knowledge. o only specify the external behavior of the system o avoid system design characteristics. You should write user requirements o in simple language o with simple tables and forms o intuitive diagrams. Problems with natural language sentences in a requirements document: 1. Lack of clarity It is sometimes difficult to use language in a precise and unambiguous way. 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. It is good practice to separate user requirements from more detailed system requirements in a requirements document. User requirements that include too much information constrain the freedom of the system developer to provide innovative solutions to user problems and are difficult to understand. The user requirement should simply focus on the key facilities to be provided. The rationale should explain why the requirement has been included. Simple guidelines to minimize misunderstandings when writing user requirements: 1. Invent a standard format and ensure that all requirement definitions adhere to that format. 2. Use language consistently. 3. Use text highlighting (bold, italic or color) to pick out key parts of the requirement. 4. Avoid the use of computer jargon. System requirements System requirements are: o Expanded versions of the user requirements that are used as the starting point for the system design. o They add detail and explain how the user requirements should be provided by the system. o They may be used as part of the contract for the implementation of the system o They should be a complete and consistent specification of the whole system. o Should simply describe the external behavior of the system and its operational constraints. o They should not be concerned with how the system should be designed or implemented. It is impossible to exclude design information from system requirements for several reasons: 1. You may have to design an initial architecture of the system to help structure the requirements specification. 2. Systems must interoperate with other existing systems. 3. The use of a specific architecture to satisfy non-functional requirements may be necessary. Natural language is often used to write system requirements specifications as well as user requirements. Disadvantages of natural language specifications: 1. Using the same words for the same concept causes confusion in understanding the specification. 2. A natural language requirements specification is over flexible. 3. There is no easy way to modularize natural language requirements. Requirements specifications written in natural language are prone to misunderstandings. Specialized notations for specifying system requirements: Structured natural language o This approach depends on defining standard forms or templates to express the requirements specification. Design description languages o This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. Graphical notations o A graphical language, supplemented by text annotations is used to define the functional requirements for the system. Mathematical specifications o These are notations based on mathematical concepts such as finite-state machines or sets. Structured language specifications Structured natural language is o System requirements are written in a standard way. The advantage of this approach is that o Maintains expressiveness and understandability of natural language o Ensures uniformity is imposed on the specification. Structured language notations limit the terminology that can be used and use templates to specify system requirements. They may incorporate control constructs derived from programming languages and graphical highlighting to partition the specification. System requirements specification using a standard form When a standard form is used for specifying functional requirements, the following information should be included: 1. Description of the function or entity being specified 2. Description of its inputs and where these come from 3. Description of its outputs and where these go to 4. Indication of what other entities are used 5. Description of the action to be taken 6. If a functional approach is used, a pre-condition and a post-condition 7. Description of the side effects of the operation. Advantage of using formatted specifications: o Variability in the specification is reduced and requirements are organized more effectively. Disadvantage of using formatted specifications: o It is difficult to write requirements in an unambiguous way, particularly when complex computations are required. Tables or Graphical models of the system can: o show how computations proceed o how the system state changes o how users interact with the system and o how sequences of actions are performed. Tables are used when a number of possible alternative situations need to described for many conditions. Tabular specification of computation Graphical models are most useful o When you need to show how state changes or o Where you need to describe a sequence of actions. Sequence of actions when a user wishes to withdraw cash from an automated teller machine (ATM) is as follows, Sequence diagram of ATM withdrawal You should read a sequence diagram from top to bottom to see the order of the actions that take place. There are three basic sub-sequences: 1. Validate card a. The userís card is validated by checking the card number and userís PIN. 2. Handle request a. The userís request is handled by the system. b. For a withdrawal, the database must be queried to check the userís balance and to debit the amount withdrawn. Notice the exception here if the requestor does not have enough money in their account. 3. Complete transaction a. The userís card is returned and, when it is removed, the cash and receipt are delivered. Interface specification If the new system and the existing systems must work together, the interfaces of existing systems have to be precisely specified. There are three types of interface that may have to be defined: 1. Procedural interfaces a. Where existing programs or sub-systems offer a range of services that are accessed by calling interface procedures. b. These interfaces are sometimes called Application Programming Interfaces (APIs). 2. Data structures a. That are passed from one sub-system to another. b. Graphical data models are the best notations for this type of description. c. Program descriptions in Java or C++ can be generated automatically from these descriptions. 3. Representations of data a. That have been established for an existing sub-system. b. These interfaces are most common in embedded, real-time system. c. The best way to describe these is to use a diagram of the structure with annotations explaining the function of each group of bits. A procedural interface definition defined in Java. Procedural interface offered by a print server. o This manages a queue of requests to print files on different printers. o Users may examine the queue associated with a printer and may remove their print jobs from that queue. They may also switch jobs from one printer to another. The functionality of the interface operations can be defined using structured natural language or tabular description. The software requirements document The software requirements document (software requirements specification or SRS) o Is the official statement of what the system developers should implement. o It should include both The user requirements for a system A detailed specification of the system requirements. Users of the requirements document: System customers o Specify the requirements and read them to check that they meet their needs. Customers specify changes to the requirements. Managers o Use the requirements document to plan a bid for the system and to plan the system development process. System engineers o Use the requirements to understand what system is to be developed System test engineers o Use the requirements to develop validation tests for the system. System maintenance engineers o Use the requirements to understand the system and the relationships between its parts The IEEE have defined standards for requirements documents. The most widely known standard is IEEE/ANSI 830-1998 (IEEE, 1998). This IEEE standard suggests the following structure for requirements documents: Preface This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version. 1. Introduction 1.1 Purpose of the requirements document This should describe the need for the system. It should describe how the system fits into the overall business or strategic objectives of the organization commissioning the software. 1.2 Scope of the product It should briefly describe its functions and explain how it will work with other systems 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the remainder of the document 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3. Specific requirements cover functional, non-functional and interface requirements. o The requirements may document external interfaces, describe system functionality and performance, specify logical database requirements, design constraints, emergent system properties and quality characteristics. 4. Appendices 5. Index 6. Glossory Glossary o This should define the technical terms used in the document. User requirements definition o The services provided for the user and the non-functional system requirements should be described in this section. System architecture o This chapter should present a high-level overview of the anticipated system architecture showing the distribution of functions across system modules. System requirements specification o This should describe the functional and non-functional requirements in more detail. System models o This should set out one or more system models showing the relationships between the system components and the system and its environment. System evolution o This should describe the fundamental assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs, etc. Appendices o These should provide detailed, specific information which is related to the application which is being developed. Index o Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, etc. Requirements Engineering The goal of the requirements engineering process is to create and maintain a system requirements document. The four high-level requirements engineering sub-processes are concerned with: o Assessing whether the system is useful to the business (feasibility study); o Discovering requirements (elicitation and analysis); o Converting these requirements into some standard form (specification); o Checking that the requirements actually define the system that the customer wants (validation). The requirements engineering process The activities in the requirement engineering process are concerned with the o discovery, o documentation o and checking of requirements. The spiral model of requirement engineering process: Spiral model of requirements engineering processes The spiral model process has three-stage organised as an iterative process. The amount of time and effort devoted to each activity depends on the stage of the overall process and the type of system being developed. Early in the process, most effort will be spent on understanding high-level business and non-functional requirements and the user requirements. Later in the process, in the outer rings of the spiral, more effort will be devoted to system requirements engineering and system modelling. This spiral model accommodates approaches to development in which the requirements are developed to different levels of detail. The number of iterations around the spiral can vary, so the spiral can be exited after some or all of the user requirements have been elicited. This model allows the requirements and the system implementation to be developed together. Feasibility studies o For all new systems, the requirements engineering process should start with a feasibility study. The input to the feasibility study is o a set of preliminary business requirements, o an outline description of the system o how the system is intended to support business processes. o The results of the feasibility study is o a report that recommends whether or not it is worth carrying on with the requirements engineering and system development process. Carrying out a feasibility study involves o Information assessment, Identifies the information that is required to answer the following questions Does the system contribute to the overall objectives of the organisation? Can the system be implemented using current technology and within given cost and schedule constraints? Can the system be integrated with present system? o Information collection You may consult information sources such as managers, software engineers, technology experts and end-users of the system. Talk with information sources to discover the answers to these questions. How would the organisation cope if this system were not implemented? What are the problems with current processes and how would a new system help alleviate these problems? What direct contribution will the system make to the business objectives and requirements? Can information be transferred to and from other organisational systems? Does the system require technology that has not previously been used in the organisation? What must be supported by the system and what need not be supported? o Report writing. Write the feasibility study report. You should make a recommendation about whether or not the system development should continue. you may propose changes to the scope, budget and schedule of the system suggest further high-level requirements for the system. Requirements elicitation and analysis In requirements elicitation and analysis activity, software engineers work with customers and system end-users to find out: about the application domain, what services the system should provide, the required performance of the system, hardware constraints, and so on. Stakeholders include End-users: who interact with the system and everyone else that may be affected by its installation. Engineers: who are developing or maintaining related systems, Business managers Domain experts Trade union representatives. Eliciting and understanding stakeholder requirements is difficult for several reasons: 1. Stakeholders often donít know what they want from the computer system except in the most general terms. 2. Stakeholders naturally express requirements in their own terms and with implicit knowledge of their own work. 3. Different stakeholders have different requirements, which they may express in different ways. 4. Political factors may influence the requirements of the system. 5. The economic and business environment in which the analysis takes place is dynamic. A general process model of the elicitation and analysis process: Model depends on local factors such as o the expertise of the staff, o the type of system being developed o the standards used. Activities within a spiral activities are interleaved as the process proceeds from the inner to the outer rings of the spiral. The requirements elicitation and analysis process The process activities are: 1. Requirements discovery a. Interacting with stakeholders in the system to collect their requirements. b. Domain requirements from stakeholders and documentation are also discovered during this activity. 2. Requirements classification and organisation a. This activity organises the unstructured collection of requirements into coherent clusters. 3. Requirements prioritisation and negotiation a. This activity is concerned with prioritising requirements, and finding and resolving requirements conflicts through negotiation. 4. Requirements documentation a. The requirements are documented and input into the next round of the spiral. b. Formal or informal requirements documents may be produced. Requirements discovery Requirements discovery is the process of o gathering information about the proposed and existing systems o filtering the user and system requirements from this information. Sources of information during the requirements discovery phase include o documentation, o system stakeholders and o specifications of similar systems. You interact with stakeholders through o interviews o observation o may use scenarios o prototypes Viewpoints Viewpoint-oriented approaches to requirements engineering organise both the elicitation process and the requirements themselves using viewpoints. A key strength of viewpoint-oriented analysis is that o it recognises multiple perspectives and o provides a framework for discovering conflicts in the requirements proposed by different stakeholders. Viewpoints can be used as a way of classifying stakeholders and other sources of requirements. There are three generic types of viewpoint: 1. Interactor viewpoints a. Represent people or other systems that interact directly with the system. 2. Indirect viewpoints a. Represent stakeholders who do not use the system themselves but who influence the requirements in some way. 3. Domain viewpoints a. Represent domain characteristics and constraints that influence the system requirements. Interviewing Formal or informal interviews with system stakeholders are part of most requirements engineering processes. The requirements engineering team puts questions to stakeholders about the system that they use and the system to be developed. Requirements are derived from the answers to these questions. Interviews may be of two types: 1. Closed interviews a. Where the stakeholder answers a predefined set of questions. 2. Open interviews a. Where there is no predefined agenda. Effective interviewers have two characteristics: 1. They are open-minded 2. They prompt the interviewee to start discussions with a question Information from interviews supplements other information about the system from documents, user observations, and so on. Scenarios Scenarios can be particularly useful for adding detail to an outline requirements description. They are descriptions of example interaction sessions. Each scenario covers one or more possible interactions. Several forms of scenarios have been developed, each of which provides different types of information at different levels of detail about the system. Using scenarios to describe requirements is an integral part of agile methods, such as extreme programming. The scenario starts with an outline of the interaction, and, during elicitation, details are added to create a complete description of that interaction. At its most general, a scenario may include: 1. A description of what the system and users expect when the scenario starts 2. A description of the normal flow of events in the scenario 3. A description of what can go wrong and how this is handled 4. Information about other activities that might be going on at the same time 5. A description of the system state when the scenario finishes. Scenarios may be written as text, supplemented by diagrams, screen shots, and so on. Alternatively, a more structured approach such as event scenarios or usecases may be adopted. As an example of a simple text scenario, consider how a user of the LIBSYS library system may use the system. Use-cases Use-cases are a scenario-based technique for requirements elicitation which were first introduced in the Objectory method. They have now become a fundamental feature of the UML notation for describing objectoriented system models. A use-case identifies the type of interaction and the actors involved. The high-level use-case of the article printing facility in LIBSYS The essentials of the use-case notation o Actors in the process are represented as stick figures, o Each class of interaction is represented as a named ellipse. The set of use-cases represents all of the possible interactions to be represented in the system requirements. Use cases for the library system The above figure develops the LIBSYS example and shows other use-cases in that environment. Use-cases identify the individual interactions with the system. They can be documented with text or linked to UML models that develop the scenario in more detail. Sequence diagrams are often used to add information to a use-case. These sequence diagrams show o the actors involved in the interaction, o the objects they interact with o the operations associated with these objects. System interactions for article printing There are four objects of classes involved in this interaction o Article, o Form, o Workspace o Printer The sequence of actions o is from top to bottom, o the labels on the arrows between the actors o objects indicate the names of operations. A user request for an article triggers a request for a copyright form. Once the user has completed the form, the article is downloaded and sent to the printer. Once printing is complete, the article is deleted from the LIBSYS workspace. The UML is a de facto standard for object-oriented modelling Ethnography Ethnography is an observational technique that can be used to understand social and organisational requirements. An analyst immerses him or herself in the working environment where the system will be used. He or she observes the day-to-day work and notes made of the actual tasks in which participants are involved. The value of ethnography is that it helps analysts discover implicit system requirements that reflect the actual rather than the formal processes in which people are involved. Ethnography and prototyping for requirements analysis Ethnography is particularly effective at discovering two types of requirements: o Requirements that are derived from the way in which people actually work rather than the way in which process definitions say they ought to work. o Requirements that are derived from cooperation and awareness of other peopleís activities. Advantage: o Ethnographic studies can reveal critical process details that are often missed by other requirements elicitation techniques. Disadvantages: o This approach is not appropriate for discovering organisational or domain requirements. o Ethnographic studies cannot always identify new features that should be added to a system. Requirements validation Requirements validation is concerned with o showing that the requirements actually define the system that the customer wants. o finding problems with the requirements. Requirements validation is important because discovering errors during development or after the system is in service is costlier. The cost of fixing a requirements problem by making a system change is much greater than repairing design or coding errors. These checks during Validation process include: 1. Validity checks A user may think that a system is needed to perform certain functions. 2. Consistency checks Requirements in the document should not conflict. 3. Completeness checks The requirements document should include requirements, which define all functions, and constraints intended by the system user. 4. Realism checks Using knowledge of existing technology, the requirements should be checked to ensure that they could actually be implemented. 5. Verifiability To reduce the potential for dispute between customer and contractor, system requirements should always be written so that they are verifiable. Requirements validation techniques: 1. Requirements reviews The requirements are analysed systematically by a team of reviewers. 2. Prototyping In this approach to validation, an executable model of the system is demonstrated to end-users and customers. 3. Test-case generation Requirements should be testable. Requirements reviews A requirements review is a manual process that involves checking the requirements document for anomalies and omissions. The review process may be managed in the same way as program inspections. Requirements reviews can be informal or formal. Informal reviews o involve contractors discussing requirements with as many system stakeholders as possible. o It is surprising how often communication between system developers and stakeholders ends after elicitation and there is no confirmation that the documented requirements are what the stakeholders really said they wanted. Formal review o The development team should Ďwalkí the client through the system requirements, explaining the implications of each requirement. o The review team should check each requirement for consistency as well as check the requirements as a whole for completeness. o Reviewers may also check for: 1. Verifiability a. Is the requirement as stated realistically testable? 2. Comprehensibility a. Do the procurers or end-users of the system properly understand the requirement? 3. Traceability a. Is the origin of the requirement clearly stated? 4. Adaptability a. Is the requirement adaptable? Conflicts, contradictions, errors and omissions in the requirements should be pointed out by reviewers and formally recorded in the review report. Requirements management The requirements for large software systems are always changing. Requirements management is the process of understanding and controlling changes to system requirements. Requirements management involves, o Keeping track of individual requirements and o Maintaining links between dependent requirements o Assessing the impact of requirements changes. o Establishing a formal process for making change proposals o Linking these to system requirements. The process of requirements management should start as soon as a draft version of the requirements document is available Enduring and volatile requirements Requirements evolution Developing software requirements focuses attention on o software capabilities, o business objectives and o other business systems. As the requirements definition is developed, you develop a better understanding of usersí needs. This feeds information back to the user, who may then propose a change to the requirements. From an evolution perspective, requirements fall into two classes: 1. Enduring requirements a. These are relatively stable requirements that derive from the core activity of the organisation b. which relate directly to the domain of the system. c. Example: in a hospital, there will always be requirements concerned with patients, doctors, nurses and treatments. 2. Volatile requirements a. These are requirements that are likely to change during the system development process or after the system has been become operational. b. Example: requirements resulting from government healthcare policies. Classification of volatile requirements: Mutable requirements o Requirements which change because of changes to the environment in which the organisation is operating. Emergent requirements o Requirements which emerge as the customerís understanding of the system develops during the system development. Consequential requirements o Requirements which result from the introduction of the computer system. Compatibility requirements o Requirements which depend on the particular systems or business processes within an organisation. Requirements management planning During the requirements management stage, you have to decide on: 1. Requirements identification a. Each requirement must be uniquely identified. 2. A change management process a. This is the set of activities that assess the impact and cost of changes. 3. Traceability policies a. These policies define the relationships between requirements, and between the requirements. 4. CASE tool support a. Tools range from specialist requirements management systems, spread sheets and simple database systems. There are three types of traceability information that may be maintained: 1. Source traceability 2. Requirements traceability 3. Design traceability The CASE tools support is required for: 1. Requirements storage 2. Change management 3. Traceability management Requirements change management Requirements change management Requirements change management should be applied to all proposed changes to the requirements. There are three principal stages to a change management process: 1. Problem analysis and change specification a. The problem or the change proposal is analysed to check that it is valid. b. The results of the analysis are fed back to the change requestor 2. Change analysis and costing a. The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements. b. The cost of making the change is estimated in terms of modifications to the requirements document 3. Change implementation a. The requirements document and the system design and implementation are modified. b. You should organise the requirements document without extensive rewriting or reorganisation.