1. ‫بسم اهلل الرحمن الرحيم‬ Sudan University of science and Technology College of graduate studies College of Computer Science and Information Technology Msc in Computer Science – Software Engineering Track Requirements EngineeringPrepared by: 1. Mohamed zeinelabdeen. 2. Omer Salih dawood.
2. Introduction:Requirements Engineering (RE) is a set of activities concerned with identifying and communicating thepurpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as thebridge between the real-world needs of users, customers, and other constituencies affected by a softwaresystem, and the capabilities and opportunities afforded by software-intensive technologies.The name“requirements engineering” may seem a little awkward. Both words carry some unfortunate connotations: „Requirements‟ suggests that there is someone out there doing the „requiring‟ – a specific customer who knows what she wants. „Engineering‟ suggests that RE is an engineering discipline in its own right, whereas it is really a fragment of a larger process of engineering software-intensive systems .Software Requirements serve two major roles in a developmental effort. They describe what to develop and Describe when the development is completed.Levels and types of requirements: Most software practitioners just talk about “the requirements.” However, by recognizing that there aredifferent levels and types of requirements, as illustrated in Figure practitioners gain a better understandingof what information they need to elicit, analyze, specify, and validate when they define their softwarerequirements. Business requirements define the business problems to be solved or the business opportunities to beaddressed by the software product. In general, the business requirements define why the software productis being developed.User requirements look at the functionality of the software product from the user‟s perspective. Theydefine what the software has to do in order for the users to accomplish their objectives. The product‟sfunctional requirements that define the software functionality must be built into the product to enableusers to accomplish their tasks, thereby satisfying the business Requirements. As opposed to the businessrequirements, business rules are the specific policies, standards, practices, regulations, and guidelines thatdefine how the users do business (and are therefore considered user-level requirements). The softwareproduct must adhere to these rules in order to function appropriately within the user‟s domain. User-levelquality attributes are nonfunctional characteristics that define the software product‟s quality. Sometimescalled the “ilities,” quality attributes include reliability, availability, security, safety, maintainability,portability, usability, and other properties. A Quality attribute may translate into product-level functionalrequirements for the software
3. That specify what functionality must exist to meet the nonfunctional attribute. For example, an ease oflearning requirement might translate into the functional requirement of having the system display pop-uphelp when the user hovers the cursor over an icon.A quality attribute may also translate into product-level nonfunctional requirements that specify thecharacteristics the software must possess in order to meet that attribute. For example, an ease-of-userequirement might translate into nonfunctional requirements for response time to user commands or reportrequests. The external interface requirements define the requirements for the information flow acrossshared interfaces to hardware, users, and other software applications outside the boundaries of thesoftware product being developed. The constraints define any restrictions imposed on the choices that thesupplier can make when designing and developing the software. For example, there may be a requirementthat the completed software use no more than 50 percent of available system memory or disk space inorder to ensure the ability for future enhancement. The data requirements define the specific data items or data structures that must be included as part ofthe software product. For example, a payroll system would have requirements for current and year-to-datepayroll data. The software may be part of a much larger system that includes other components. In this case, thebusiness and user-level requirements feed into the product requirements at the system level. The systemarchitecture then allocates requirements from the set of system requirements downward into the software,hardware, and manual operations component .Characteristics of good requirements :Characteristic ExplanationUnitary The requirement addresses one and only one thing.Complete The requirement is fully stated in one place with no missing information.Consistent The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.Atomic The requirement is atomic.Current The requirement has not been made obsolete by the passage of time.Unambiguous the requirement is concisely stated without recourse to technical jargon.Verifiable The implementation of the requirement can be determinedFeasible The requirement can be implemented within the constraints of project.Requirements Engineering Process:
4. 1. Requirements Elicitation :Software product development must begin by gathering the different kinds of requirements from suitablestakeholders. The critical first step is to …1.1. Define the Product‟s Business Requirements:The business requirements should articulate how the product‟s developers and their customers will benefitfrom this product, what the product could ultimately become, and the project‟s scope .1.2. Get Extensive User Involvement:Multiple studies indict insufficient user involvement as a common reason why software projects struggleand fail. Every project should identify its distinct user classes and their characteristics. Users might differin their frequency of product use, features used, privilege levels, or skill levels.1.3. Focus on User Tasks:The use case approach is all the rage in software requirements circles these days and is one fad I endorse.A use case describes a task the user must be able to perform with a software product. Use cases shiftrequirements discussions from the traditional focus on features and functionality to the perspective ofwhat the user will do with the product. This change in perspective is more important than whether youdraw elaborate use case models .1.4. Define Quality Attributes:Quality attributes include characteristics that users can observe as well as those that are primarilyimportant to developers .Users might care immensely about system availability, efficiency, integrity,reliability, robustness, and usability.1.5. Elicitation techniques:The choice of elicitation technique depends on the time and resources available to the requirementsengineer, and of course, the kind of information that needs to be elicited. We distinguish a number ofclasses of elicitation technique:Traditional techniques: These include the use of questionnaires and surveys, interviews, and analysis ofexisting documentation such as organizational charts, process models or standards, and user or othermanuals of existing systems .Group elicitation techniques: They include brainstorming and focus groups, as well as RAD/JADworkshops (using consensus-building workshops with an unbiased facilitator) .Prototyping: has been used for elicitation where there is a great deal of uncertainty about therequirements, or where early feedback from stakeholders is needed .Model-driven techniques: These include goal-based methods, such as KAOS  and , and scenario-basedmethods such as CREWS .Cognitive techniques: include a series of techniques originally developed for knowledge acquisition forknowledge-based systems . Such as protocol analysis, laddering, card sorting and repertory grids.Contextual techniques: emerged in the 1990‟s as an alternative to both traditional and cognitivetechniques . These include the use of ethnographic techniques such as participant observation. Theyalso include ethnomethodogy and conversation analysis, both of which apply fine grained analysis toidentify patterns in conversation and interaction .2. Requirements Analysis:Requirements analysis includes decomposing high-level requirements into detailed functionalrequirements, constructing graphical requirements models, and building prototypes. Analysis models andprototypes provide alternative views of the requirements, which often reveal errors and conflicts that arehard to spot in a textual SRS. Another important analysis activity is to...2.1. Prioritize RequirementsAny project with resource limitations must establish the relative priorities of the requested features, usecases, or functional requirements. Prioritization helps the project manager plan for staged releases, maketrade-off decisions, and respond to requests for adding more functionality. Prioritization often becomes
5. politically and emotionally charged, with all stakeholders insisting that their needs are most important. Abetter approach is to base priorities on some objective analysis of how to deliver the maximum productvalue within the schedule, budget, and staff constraints .3. Requirements Specification:The most essential specification key practice is to write down the requirements in some accepted,structured format as you gather and analyze them. The objective of requirements development is tocommunicate a shared understanding of the new product among all project stakeholders. Historically, thisunderstanding is captured in the form of a textual SRS written in natural language, augmented byappropriate analysis models .4. Requirements Verification:Verification involves evaluating the correctness and completeness of the requirements, to ensure that asystem built to those requirements will satisfy the users‟ needs and expectations. The goal of verificationis to ensure that the requirements provide an adequate basis to proceed with design, construction, andtesting. A powerful way to achieve this goal is to Inspect Requirements Specifications because it costs somuch more to fix defects later in the development process, formal inspection of requirements is perhapsthe highest leverage software quality practice available. Who have successfully implementedrequirements inspections find them to be tedious, slow, painful, and worth every minute because so manydefects are found so cheaply. Combining formal inspection with incremental informal requirementsreviews provides a powerful approach to building quality into your product .Requirements Document Standards:There are Several Standards for Requirements Documents exist :1- IEEE Standard 1362-1998.Developed by IEEE, it presents a template that may be used to specify user requirements. The templatedescribes: 1- Current situation (without system). 2- Justification for change (why new system). 3- Description of proposed system (high level).2 - IEEE Standard 830-1998Developed by IEEE, it presents a template that may be used to specify developer requirements (sometimes it is partially used to describe user developer requirementsas it contains parts that are on a higher level) .The template describes: 1- Overview of the system. 2- Justification for change (why new system). 3- Description of proposed system (high level).3- Volere Template:Developed by James & Suzanne Robertson (The Atlantic Systems Guild),it Presents a template that maybe used to specify user requirements as well as developer requirements:
6. 1- Some template sections describe very detailed information about the system while other sections are very high level (developer vs. user).2- Some template sections can be used for a developer audience as well as auser audience.In these cases either the used notation is the key differentiator or the information contained in the userdocument is refined in the developer section.Conclusion:Many delivered systems do not meet their customers‟ requirements due, at least partly, to ineffective RE.RE is often treated as a time-consuming, bureaucratic and contractual process. This attitude is changing asRE is increasingly recognized as a critically important activity in any systems engineering process. Thenovelty of many software applications, the speed with which they need to be developed, and the degree towhich they are expected to change, all play a role in determining how the systems development processshould be conducted. The demand for better, faster, and more usable software systems will continue, andRE will therefore continue to evolve in order to deal with different development scenarios. We believethat effective RE will continue to play a key role in determining the success or failure of projects, and indetermining the quality of systems that are delivered.References: 1- Draft – Please do not circulate- chapter 1- What is Requirements Engineering- page 2. 2- Software Requirements Engineering: What, Why, Who, When, and How- By Linda Westfall. 3- Requirements Engineering- Standards Natural Language Requirements- -WS 2010/2011-Lecture- by Jörg Dörr. 4- http://en.wikipedia.org/wiki/Requirement#Requirements_in_systems_and_software_engineering. 5- http://www.processimpact.com/articles/telepathy.html 6- Maiden, N. & Rugg, G. (1996). ACRE: Selecting Methods for Requirements Acquisition. Software Engineering Journal, 11(3): 183-192. 7- Davis, A. (1992). Operational Prototyping: A New Development Approach. Software, 9(5): 70-78. 8- Chung, L., Nixon, B., Yu, E. & Mylopoulos, J. (2000). Non- Functional Requirements in Software Engineering. Boston: Kluwer Academic Publishers. 9- Van Lamsweerde, A., Darimont, R. & Letier, E. (1998). Managing conflicts in goal-driven requirements engineering. IEEE Transactions on Software Engineering, 24(11): 908-926. 10- Maiden, N. (1998). CREWS-SAVRE: Scenarios for Acquiring and Validating Requirements. Automated Software Engineering, 5(4): 419-446. 11- Shaw, M. & Gaines, B. (1996). Requirements Acquisition. Software Engineering Journal, 11(3): 149-165. 12- Goguen, J. & Linde, C. (1993). Techniques for Requirements Elicitation. 1st IEEE International Symposium on Requirements Engineering (RE93), San Diego, USA, 4-6th January 1993, pp. 152- 164. 13- Viller, S. & Sommerville, I. (1999). Social Analysis in the Requirements Engineering Process: from ethnography to method. 4th International Symposium on Requirements Engineering (RE99), Limerick, Ireland, 7-11th June 1999.