SYSTEMS ANALYSIS project
daven9947
06_SystemsAnalysis-Fall2019-Week61.pdf
1
ISMM1-UC 752: SYSTEMS ANALYSIS
Fall 2019 – Lecture 6 Instructor: Dr. Antonios Saravanos
1
The Birth of Requirements
• Requirements-driven processes were established in the 1956 SAGE process model
• Requirements Analysis can be first seen in 1977 method for Structured Analysis and Design Techniques (Ross)
• Academia – First International Conference was held in 1993 – Dedicated Journal published in 1996
• International Requirements Engineering Board – Certified Professional for Requirements Engineering (CPRE)
2
2
2
What is a Requirement?
• A requirement is simply a statement of what the system must do or what characteristic it must have.
Source: Systems Analysis and Design with UML
3
3
IEEE Definition of "Requirement"
• A condition or capability needed by a user to solve a problem or achieve an objective.
• A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
• A documented representation of a condition or capability as in (1) or (2).
4
4
3
Definitions of Requirements Analysis
• “The systematic process of developing requirements through an iterative process of analyzing a problem, documenting the resulting observations, and checking the accuracy of the understanding gained” (Loucopoulos & Champion, 1989).
• “Software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation” (Nuseibeh, 2001).
5
5
Requirements and Understanding Work
• The British Computer Society (BCS) recommends that requirements engineers: – Strive to understand the organization's business and search for changes
that will bring tangible benefits – Be aware of the impact of new or changed solutions on people’s
working lives and deal sensitively with them – When analyzing current practices, show respect for people at all levels
of the organization
• (Source: British Computer Society Good Practice Guide, Sec 5.1)
6
6
4
Business vs. System Requirements.
• Requirements written from the perspective of the business are known as business requirements.
• Requirements that are written from the developer’s perspective are usually called system requirements.
7
7
Requirements are a Measure of Success
• The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. Requirements analysis is the process of discovering that purpose (Nuseibeh & Easterbrook, 2000).
8
8
5
Requirements Can Lead to Project Failure
• "Accurately capturing system requirements is the major factor in the failure of 90% of large software projects" (Davis et al, 2006).
• "Poor requirements management can be attributed to 71% of software projects that fail; greater than bad technology, missed deadlines, and change management issues" (Lindquist, 2005).
9
9
Types of Problems
• Problems of scope – the boundary of the system is ill-defined – unnecessary design information may be given
• Problems of understanding – users have incomplete understanding of their needs – users have poor understanding of computer capabilities and limitations – analysts have poor knowledge of problem domain – user and analyst speak different languages – ease of omitting “obvious” information – conflicting views of different users
• Problems of volatility – requirements evolve over time
(Source: Issues in Requirements Elicitation by Christel & Kang, 1992)
10
10
6
Types of Requirements
Generally, one can distinguish between three types of requirements: • Functional Requirement
– A functional requirement is a requirement concerning a result of behavior that shall be provided by a function of the system.
• Quality/Non-Functional Requirement • A quality requirement is a requirement that pertains to a quality concern
that is not covered by functional requirements. Typically, quality requirements are about the performance, availability, dependability, scalability, or portability of a system. Requirements of this type are frequently classified as non-functional requirements.
• Constraint – A constraint is a requirement that limits the solution space beyond what
is necessary for meeting the given functional requirements and quality requirements. E.g. 1: The system shall be implemented using web services. E.g. 2: The system shall be available on the market no later than the second quarter of 2014.
(Source: Requirements Engineering Fundamentals) 11
11
12
7
13
Requirements Characteristics
• Needed – A requirement is a statement of something someone needs. It
distinguishes between a need and a want. A requirement that is not necessary is not a good requirement.
• Verifiable – A requirement must state something that can be verifiable by inspection,
analysis, test, or demonstration. Identify how to prove that a product meets the requirement when writing or reviewing a requirement.
• Attainable – A requirement must be attainable within foreseeable budget and schedule,
and must be technically feasible. This is particularly important for the technical requirements. Higher level “Operational Requirements” may be developed without assurance of budget or schedule, but they must be technically feasible
• Clear – A requirement expresses a single thought. It cannot be misunderstood. It
is concise, simple, and grammatically correct. (Source: http://www.srh.noaa.gov/srh/ssd/html/requirement.pdf) 14
14
8
Remember
• Requirements should specify ‘what’ but not ‘how’
15
15
Requirements Analysis Strategies
• The basic process of analysis is divided into: 1. Understanding the as-is system 2. Identifying improvements 3. Developing requirements for the to-be system
• There are 3 requirements analysis strategies 1. Business process automation 2. Business process improvement 3. Business process reengineering
16
9
Business Process Automation
• BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work
• Low risk, but low payoff • Planners in BPA projects invest significant time in
understanding the as-is system using: – Problem analysis – Root cause analysis
17
Problem Analysis
• Users and managers identify problems with the as-is system and describe how to solve them in the to-be system
• Tends to solve problems rather than capitalize on opportunities
• Improvements tend to be small and incremental
18
10
Root Cause Analysis
• Users are not asked for solutions, but for: – A list of (prioritized) problems – All possible root causes for those problems
• Analysts investigate each root cause to find: – Solutions for the highest priority problems – Root causes that are common to multiple problems
19
Root Cause Analysis Example
20
11
Business Process Improvement
• BPI makes moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing
• Common activities: – Duration analysis – Activity-based costing – Informal benchmarking
21
Business Process Reengineering
• BPR changes the fundamental way in which the organization operates
• Spends little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing business
• Popular activities: – Outcome analysis – Technology analysis – Activity elimination
22
12
Selecting the Appropriate Strategies
Business Process Automation
Business Process Improvement
Business Process Reengineering
Potential benefit Low–moderate Moderate High Project cost Low Low–moderate High Breadth of analysis
Narrow Narrow-moderate Very broad
Risk Low–moderate Low–moderate Very high
23
