SYSTEMS ANALYSIS project

daven9947

SystemsAnalysisandDesign-Fall2019-Week10.pdf

Home >Information Systems homework help >SYSTEMS ANALYSIS project

ISMM1-UC 752: SYSTEMS ANALYSIS

Fall 2019 – Lecture 10 Instructor: Dr. Antonios Saravanos

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)

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

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).

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).

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)

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.

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).

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).

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)

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

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

Remember

• Requirements should specify ‘what’ but not ‘how’

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

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

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

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

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

Requirements Tools

• Interviews • Facilitated Workshops • Fieldwork • Surveys • Scenarios • Domain Modeling • System Modeling • Formal Notations • Information Notation • Templates • Use Cases • Check-lists • Managements Tools • Prototyping

Common Methods

• Focus-Group • Questionnaire (Survey) • Site Visit • Usability Study • Market Research

Choosing Methods

• The challenges of requirements elicitation cannot be solved in a purely technological way (Gougen & Linde, 1993)

• One of the most difficult jobs for requirements engineers is to select an appropriate RE method for a project at hand (Tsumaki & Tamai, 2005)

• RE analysts select a particular elicitation technique for any combination of four reasons (Hickey & Davis, 2003) – It is the only technique that the analyst knows – It is the analyst's favorite technique for all situations – The analyst is following some explicit methodology, and that

methodology prescribes a particular technique at the current time – The analyst understands intuitively that the technique is effective in the

current circumstance

Requirements vs. Specifications

• What are the differences between the specification process and the requirements process? – Requirements are what the user wants and is a contract between the

user and the development. – Specifications are what the computer will do and are a “contract”

between the developers and the computer.

Requirements and the Social Sciences

• Many methods can be used to elicit requirements such as: – Ethnography – Questionnaires – Interviews – Focus groups

• Note that these are methodologies based on the social sciences

Requirements Elicitation

• System requirements • User requirements • Information about:

– Stakeholders – Users' work activities – Users' working environment

Overview

• Let’s focus on two key methods for now: – Questionnaires – Interviewing

Questionnaires

• Distributed through – paper – Electronically via the internet

• Can access a large population quickly • Low cost • Good for gathering

– Opinions – Knowledge

• Are there any disadvantages?

Questionnaire Design

• Decide on the most important issues – This can be hard, particularly if it is an exploratory

• Reliability: would you get the same results if • you repeated the exercise? • ! Validity: does it actually measure what you • intended it to? • ! Word questions unambiguously • ! Sample size

Choosing Methods

• One of the most difficult jobs for requirements engineers is to select an appropriate RE method for a project at hand.

• RE analysts select a particular elicitation technique for any combination of four reasons : – It is the only technique that the analyst knows – It is the analyst's favorite technique for all situations – The analysis following some explicit methodology, and that

methodology prescribes a particular technique at the current time – The analyst understands intuitively that the technique is effective in the

current circumstance

(Source: Elicitation technique selection: How do experts do it)

Closed Question Example

Which areas have you worked on in software development projects?

A. Business Modeling Testing B. Feasibility Studies Installation C. Systems Specification Maintenance D. Design Management E. Implementation Other

Closed Questions

• Advantages – Quick for participant to complete – Easy to process

• Disadvantages – Participant given limited set of choices – Possible choices must be determined in advance

Open Question Example

• Which of the above features would most improve the current system? (Please explain why.)

Open Questions

• Advantages – Responses can be more fully developed by respondent – Helpful for exploratory areas

• Disadvantages – Responses may be ambiguous, incomplete or hard to categories – More effort for participants – More effort for analyst

Open vs. Closed Questions

In general: • You should use closed questions:

– Where all the alternative replies are known, limited in number, and clear cut

• You should use open questions: – When the issue is more complex, where all the dimensions are not

known, and the area is more exploratory

When Writing Questions…

• Be Clear – Use simple and uncomplicated sentences

• Reduce ambiguity – Be specific, e.g. “twice a week”, rather than “often” – Ensure questions are appropriate to audience – Is the question relevant to this participant? – Do they have the knowledge to answer? – Will they be willing to reveal the information?

• Be careful – Avoid with sensitive topics

• Filter Questions – Guide respondent through the questions avoiding those that are

irrelevant – This will avoid confusion and wasting of the time of those completing

your questionnaire 36

Interviews

• Structured Interviews – Questions are written in advance – Read to the subject in the same way each time – Often contains closed-ended questions

• Semi-Structured Interviews – May contain open-ended questions – Order in which the questions are taken by subject do not have to be

identical • Unstructured Interviews

Interviews

• Structured Interviews – Questions are written in advance – Read to the subject in the same way each time – Often contains closed-ended questions

• Semi-Structured Interviews – May contain open-ended questions – Order in which the questions are taken by subject do not have to be

identical • Unstructured Interviews

• What are the advantages and disadvantages of each approach?

Interview Data

• Can take notes • Can record

– Remember for consent to record – Transcribe your recordings

• What are the advantages and disadvantages of each approach?

Interview Analysis

• Different methods of analysis – Grounded Theory – Discourse Analysis

Things to Avoid

• Leading questions – Don’t you think that a computer network would benefit you by bringing

you in closer contact with your colleagues? • Double-barreled questions

– Do you need to travel for work and do you enjoy it? • Hypothetical questions

– What would you do if the company was taken over? • Secondary information

– What does your supervisor think about this?

The Problematic Nature of Requirements

• Requirements change • Difficult to write • Feature creep • Not well organized • Are influenced by multiple sources • Not always easy to express clearly in words • Requirements may have different levels of detail • Number of requirements can become unmanageable • Requirements are related to one another

Requirements Specification

• Resource for coming to agreement • Acts as a basis for software design activities • Useful for verifying what's been built

Modeling • An abstract representation of a system from a specific point of view

– A model expresses the essentials of a situation – A model does not give unnecessary information

• The Unified Modeling Language (UML) is general-purpose modeling language in the field of software engineering a standardized (ISO 19501)

Five Basic Steps of Interviews

• Selecting interviewees • Designing interview questions • Preparing for the interview • Conducting the interview • Post-interview follow-up

Slide 45

Slide 46

Selecting Interviewees

• Based on information needed • Often good to get different perspectives

– Managers – Users – Ideally, all key stakeholders

Interviewing Strategies

How can order

processing be improved?

How can we reduce the number of times that customers

return ordered items?

How can we reduce the number of errors in order processing (e.g., shipping

the wrong products)?

Top-down

Bottom-up

High-level: Very general

Medium-level: Moderately specific

Low-level: Very specific

Post-Interview

Joint Application Development

• Allows the project team, users, and management to work together to identify requirements for the system

• Often the most useful method for collecting information from users

• Key roles: – Facilitator – Scribe

JAD Meeting Room

JPEG Figure 5-5 Goes Here

The JAD Session

• Tend to last 5 to 10 days over a three week period • Prepare questions as with interviews • Formal agenda and ground rules • Facilitator activities

– Keep session on track – Help with technical terms and jargon – Record group input – Help resolve issues

• Post-session follow-up

Managing Problems in JAD Sessions

• Reducing domination • Encouraging non-contributors • Side discussions • Agenda merry-go-round • Violent agreement • Unresolved conflict • True conflict • Use humor

Questionnaires

• A set of written questions used to obtain information from individuals

• Often used for large numbers of people from whom information and opinions are needed

• Common technique with systems intended for use outside the organization

• Response rates vary, but typically are significantly less than 50%

Questionnaire Steps

• Selecting participants – Using samples of the population

• Designing the questionnaire – Careful question selection

• Administering the questionnaire – Working to get good response rate

• Questionnaire follow-up – Send results to participants

Good Questionnaire Design

• Begin with non-threatening and interesting questions

• Group items into logically coherent sections

• No important items at the very end • Do not crowd a page with too many items • Avoid abbreviations • Avoid biased or suggestive items or terms • Number questions to avoid confusion • Pretest to identify confusing questions • Provide anonymity to respondents

Document Analysis

• Provides clues about existing “as-is” system • Typical documents

– Forms – Reports – Policy manuals

• Look for user additions to forms • Look for unused form elements

Observation

• Users/managers often don’t remember everything they do

• Checks validity of information gathered other ways • Behaviors change when people are watched • Careful not to ignore periodic activities

– Weekly … Monthly … Annual

Other Techniques

• Throw-away prototyping • Role playing CRC cards with use cases • Mind/concept mapping

Selecting Appropriate Techniques

Interview JAD Question -naires

Documen t Analysis

Observati on

Type of information

As-is, improves, to-be

As-is, improves

As-is As-is

Depth of info High High Medium Low Low Breadth of info Low Medium High High Low Info integration Low High Low Low Low User involvement

Medium High Low Low Low

Cost Medium Low- medium

Low Low Low- medium