Software Requirements Engineering Lecture #3, Slides of Software Engineering

Download Software Requirements Engineering Lecture #3 and more Slides Software Engineering in PDF only on Docsity! SOFTWARE REQUIREMENTS ENGINEERING LECTURE # 3 a0) >) PA AYR A Presentation Outline 4  The Software Team  Problem Analysis 5 Steps of Problem Analysis  Gain Agreement on the Problem Definition Understand the Root Causes Identify the Stakeholder and Users  Define the Solution System Boundary  Identify the constraints to be imposed on the solution The Software Team6  Effective requirements management can be accomplished only byan effective s ftware team.  Requirements management touches every team member in different ways.  Effective requirements management requires mastering six team skills. Team Members Have Different Skills7  One of the most interesting things about teams is that individual teammembers have different skills, that's what makes a team.  In the software team, we hope that Some players have proven their ability to work with the customers effectively,  Some have software programming abilities, and that  others have testing abilities.  Still other team players will need design and architecture abilities.  Many more skills are required as well. Requisite Team Skills for Effective Requirements Management 8  six team skills that are necessary for a modern softw re team tosuccessfully address the requirements challenge are mentioned here  Team Skill 1, Analyzing the Problem  Team Skill 2, Understanding User and Stakeholder Needs  Team Skill 3, Defining the System  Team Skill 4, Managing Scope  Team Skill 5, Refining the System Definition  Team Skill 6, Building the Right System Team Members Project Management Skills Requirements Engineer / size and business cops requirements formation project sponsor project management USSF — p> quae, nal and ST a fequirements development user representatives Requirements Analyst functional and ak nonfunctional eee requirements testing other stakeholders Tasks of Requirements Engineer /Analyst [2]11  Define Business Needs.  Identify Project Stakeholders and user classes  Elicit Requirements  Analyze Requirements  Write Specifications Tasks of Requirements Engineer /Analyst [2]12  Model the Requirements  Lead Validation  Facilitate Prioritization  Manage Requirements 5Steps of Problem Analysis [1]15  The goal of problem analysis is to gain a better understanding, before developmentbegins, of the problem being solved. 1. 2. Gain agreement on the problem definition. Understand the root causes—the problem behind the problem. 3. 4. 5. Identify the stakeholders and the users. Define the solution system boundary. Identify the constraints to be imposed on the solution. Gain Agreement on the problem definition16  The first step is to gain agreement on the definition of the problem to be solved.  One of the simplest ways to gain this agreement is to simply write the problem downand see whether everyone agrees. The problem Statement17  You may find it helpful to write your problem down in astandardized format (Table 1). Table 1: Problem Statement Format Proble m Descripti on The Problem of Affects Describe the problem.Identify stakeholders affected by the problem.The result of which Describe the impact of this problem on stakeholders and business activity. Benefits of Indicate the proposed solution and list a few key benefits. Step 2: Understand the Root Causes20  OK, so how do you determine the root causes? In many cases, it's a simple matterof asking the people directly involved what they think the root cause is.  If the problem is more serious then it may be necessary to perform a detailedinvestigation of each contributing problem and to quantify its individual impact.  This could vary from perhaps simple brainstorming by participants to a small data collectionproject or, pote tially, to a more detailed experiment. Addressing the Root Cause21  let's look at the problem analysis sequence that got us here  A further fishbone analysis could then be used to determine what specific types oferrors contribute to the inaccurate sales order problem.  This new, more detailed data can then be used to define the features of the software system toadd ss those errors. Figure 3: Pareto Chart of Root Causes Addressing the Root Cause22  We might like to fix all of the root causes on the "bones" of the diagram.  But data shows that a number of root causes are simply not worth fixing, as the cost of the fixxceeds the cost of the problem.  How do you know which ones to fix? You must determine the contribution, of each root cause. The results of this investigation can be plotted as a Pareto chart [3] or a simple histogram [4] that visually exposes the real culprits. Figure 4: Pareto Chart of Root Causes Step 3: Identify the Stakeholders and the Users25  Understanding the needs of the users and other stakeholders is a key factor indeveloping an effective solution.  Effectively solving any complex problem typically involves satisfying the needs of adiverse group of stakeholders.  Many stakeholders are users of the system, and their needs are easy to focus onbecause they will be directly involved with system use.  However, some stakeholders are only indirect users of the system or are affected only by thebusiness outcom s that the system influences.  For example, they include the people and organizations involved in the development ofthe system, the subcontractors, the customer's, e.t.c Step 3: Identify the Stakeholders and the Users26 The following questions can be helpful in this process.  Who are the users of the system?  Who is the customer (economic buyer) for the system?  Who else will be affected by the outputs the system produces?  Who will evaluate and approve the system when it is delivered and deployed?  Are there any other internal or external users of the system whose needs must be addressed?  Who will maintain the new system?  Is there anyone else who cares? W5H2 Step 4: Define the Solution System Boundary27  Once the problem statement is agreed to and the users and stakeholders are identified, we can turn our attention to defining a system that can be deployed to address the problem. In s oing, we enter an important transition state wherein we have to keeptwo things in mind:  an understanding of the problem and  the considerations of a potential solution. The next important step is to determine the boundaries of the solution system. The system boundary defines the border between the solution and the real world that surrounds the solution (Figure 4). Information, in the form of inputs and outputs, is passed back and forth fromthe system to users. Figure 4: The inputs/system/outputs relationship Step 4: Define the Solution System Boundary29  H w do we find these actors? Here are some helpful questions to ask.  Who will supply, use, or remove information from the system?  Who will operate the system?  Who will perform any system maintenance?  Where will the system be used?  Where does the system get its information?  What other external systems will interact with the system? Step 4: Define the Solution System Boundary30  After identifying the actors, the analyst can now create a "system perspective," a block diagram that describes the boundaries of the system, the users, and other interfaces. Figure 6 provides a system perspective for the new sales order system.  The dotted lin illustrates the system boundary for the proposed solution. The diagram shows that in order to solve our problem we will have to both develop a new system and modify some elements of the existing system (legacy system). Figure 5: System Perspective Step 5: Identify the Constraints to Be Imposed on the Solution31  Constraints are restrictions on the degrees of freedom we have inproviding a solution.  Each constraint has the potential to severely restrict our ability to deliver a solution as we visualize it. Therefore, each constraint must be carefully considered as part of the planning process. A vari ty of sources of constraints must be considered.  These constraints may be given to us before we even begin or we may have toactively elicit them.