Requirements analysis Speaker: Chuang-Hung Shih Date:

Understanding what the customer wants  Analysis should come early in any project, and the most important part of that analysis is the gathering of business requirements.  Learn about product and process requirements and how to effectively determine and prioritize customer needs.  Business requirements are statements that describe what the customer and major stakeholders need and want.

All about requirements  Product requirements Product requirements describe the business needs in terms of the main deliverables or products that are created  Process requirements Process requirements describe how people interact with a product and how a product interacts with other products.  Prioritize the requirements Fulfilling some requirements requires much more effort and cost than others.

Beware of false requirements  If you could ask your customers what their requirements were and have them respond with everything they needed. A number of challenges must be overcome: No single customer normally knows all of the requirements up front. Different customers have different visions of what the business needs are. Requirements are vague. Many statements are not requirements.

Success criteria  The table below lists the criteria for software project success in order of importance.

Requirements analysis process  Requirements analysis process: Requirements elicitation, analysis and specification.  Requirements analysis is the process of understanding the customer needs and expectations from a proposed system or application and is a well-defined stage in the Software Development Life Cycle model.  Software requirements analysis and documentation processes are critical to software project success.

Requirements analysis process  Steps in the requirements analysis process. I. Fix system boundaries  This initial step helps in identifying how the new application integrates with the business processes, how it fits into the larger picture and what its scope and limitations will be. II. Identify the customer  In more recent times there has been a focus on identifying who the 'users' or 'customers' of an application are. III. Requirements elicitation IV. Requirements Analysis Process  Once all stakeholder requirements have been gathered, a structured analysis of these can be done after modeling the requirements. V. Requirements Specification VI. Requirements Management

Requirements elicitation  Information is gathered from the multiple stakeholders identified.  Problems faced in Requirements Elicitation. Ambiguous understanding of processes Inconsistency within a single process by multiple users Insufficient input from stakeholders Conflicting stakeholder interests Changes in requirements after project has begun  Tools used in Requirements Elicitation. Some of the current Requirements Elicitation tools in use are: Prototypes Use cases Data flow diagrams Transition process diagrams User interfaces

Requirements specification  Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous terms.  To overcome this, Requirements Specifications may be documented separately as User Requirements - written in clear, precise language with and use cases, for the benefit of the customer and end-user System Requirements - expressed as a programming or mathematical model, addressing the Application Development Team and QA( Quality Assurance) and Testing Team.

Your project's analysis phase should yield three critical documents  When the analysis phase of an application development project ends, a manager should know what the application looks like, how it functions, and how it is designed.  The three important deliverables created during this phase are: The business requirements report. The conceptual systems design plan. The strategy documents.

The business requirements report  High-level requirements This section defines the big-picture requirements that are common to the entire solution.  Functional requirements These are the more specific requirements.  Acceptance criteria This section should describe the client ’ s criteria for accepting the application, if it has not already been described elsewhere.  Process model If you created process models of the solution, they should be included here, along with the appropriate descriptions.  Data model  Additional information Depending on the project and the particulars of the analysis phase, you may also need to include any assumptions made in the analysis process and other models, such as context diagrams, process decompositions, and entity diagrams.

Conceptual systems design plan  High-level technical architecture This is a place to start laying out the technical solution. It should be diagram at a high level that the business customer can understand.  Screen layouts However, a better way is to work with the business client to define what the screens should look like and then design and code to those general specifications.  Report layouts Work with your clients to define the reports that are needed and the general columns and selection criteria of the reports.  Interfaces At this point, you should have a general idea of the internal and external interfaces needed for the solution.

High-level strategy documents  Testing strategy The purpose of the testing strategy is to define the overall context for the entire testing process. The process depends on the specific characteristics of your solution.  Training strategy The information includes a training overview, the training needs of the stakeholders, the types of training to be offered, and how the training will be built and delivered.  Data conversion strategy In this document, you describe at a high level how data will be converted from the current applications to the new application.  Implementation strategy When your application is completed, it may need a formal deployment strategy. This document provides a general overview of deployment, when it will occur, the complexities and risks, any assistance at the deployed sites, and other relevant details.

User Participation in Software Development Projects  It Is commonly acknowledged that success In IT projects is difficult to achieve. A recent industry survey observed that only 34% of IT projects were considered successful.  Of the several potential factors contributing to this hard-to- achieve success, user involvement was noted as the most important one.  Researchers and practitioners have viewed user participation as an important way of improving software quality and increasing user satisfaction and acceptance.  On the other hand, empirical evidence shows that user participation in the development process can negatively influence project performance since it could make the process more difficult, lengthy, and less effective.

User Participation in Software Development Projects  This article addresses the question of the relative effectiveness of user participation by empirically examining the perceived software project performance (for example, satisfaction) from both user and developer perspectives simultaneously.  We used survey data from 117 software development projects and 746 respondents at a large Fortune 100 manufacturing firm during a four-year time period to investigate the impact of user participation on the satisfaction of both developers and users.  In addition, we also study the role of software complexity (for example, whether projects involve new software development as opposed to maintenance of existing software) in user participation and its effect on satisfaction.

User Participation in Software Development Projects  Questionnaire data was collected from 453 software developers and 293 users/customers working on 117 software projects.  Of the 117 software development projects, 45 (39% of our sample) were maintenance projects and 72 (61%) were new development projects. The average software development time of the 117 software projects was 126 days.

The Level of User Participation  Projects with nonzero participation greater than the median (> 0.462) were categorized as high participation. Of the 72 new development projects, 19 (26%) had low (very minimal), 26 (36%) had moderate, and 27 (38%) had high user participation.  On the other hand, of the 45 maintenance projects, 15 (33%) had low, 16 (36%) had moderate, and 14 (31%) had high user participation in the development process.

New Development Project Satisfaction  Low user-participation An X-shaped effect suggests that users were most satisfied while developers were significantly less satisfied in the low (minimal) user-participation situation. Developers, under such circumstances, were likely to find greater difficulty in resolving requirements and product feature ambiguities.

New Development Project Satisfaction  Moderate user-participation Users participated for an average of 3.88 workdays for a 100 function point project, implying 28 workdays of customer effort for an average new development project (711 function points, corresponding to 127 calendar days). In other words, users invested approximately 22% as much as the overall project development time. Even though the satisfaction levels were not at their highest, developers and users seemed to reach a common ground when users engage only moderately in the development process.  High user-participation In our sample, a project in this group (high participation), exhibited an average of 105 workdays of customer participation, in comparison to 28- workday effort for a moderate participation project, for an average of 127- workday project. Users participate to such extreme levels, their expectations of project outcomes could also be exceptionally high. These users are then very unlikely to be satisfied if actual project outcomes do not perform to their high expectations

Maintenance Project Satisfaction  Low user-participation Both software developers and users were unlikely to be fully satisfied with low user-participation in maintenance projects. This effect may be due to the fact that software maintenance is a task that is fairly difficult to execute and manage effectively due to added complexity of understanding prior written code and prior corrective repairs on the baseline software code.

Maintenance Project Satisfaction  Moderate user-participation That is, users participated approximately 15% as much as the overall project development time. When users are involved in such maintenance projects (moderate participation), they might be able to lower developers' frustration and enhance developers' overall software comprehension since users tend to know more about the features in the original software.  High user-participation In our data, users and developers were relatively less satisfied when users participated for approximately 75 workdays (60% of the overall project development time). Even if the original software is well-developed, the maintenance task is relatively less complicated, and the overall maintenance project is completed with fairly minimal changes in scope, the high expectations of users might remain unsatisfied. At the same time, software developers are likely to be unhappy with over demanding customers/users.