Modern Systems Analysis and Design Seventh Edition Jeffrey

Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 6 Determining System Requirements

Performing Requirements Determination FIGURE 6 -1 Systems development life cycle with analysis phase highlighted Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 2

Requirements Engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. n The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. n

Types of requirement: A-User requirements ¨ Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers. n n n Example User requirements: generating monthly report showing name of item sold, quantity sold, total amount of money, what is left in store and so on. A report showing the total amount of spending by each department in the university.

B- System requirements: ¨ n n n A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented. it may be part of a contract between client and contractor. Examples: At the last day of a month the system generates an absence report for each student. A copy of the report is generated for the student's course instructor, another copy for the student's major department head another copy for the student's parents. At the end of each phone call, a message is sent back to caller showing call duration, call cost and the remaining balance in minutes or money.

Business requirements n Business requirements for a project are a series of needs that must be fulfilled to achieve a high-level objective. For example, if a company's objective is to upgrade its manual payroll process by switching to an automated payroll process, the business requirements for the project might be described as, 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 6

"implement a computerized system that reduces errors and increases efficiency by calculating employees' wages, withholding required deductions and paying the employee the amount she is owed. " Clear business requirements help ensure that the end result of a project fulfills the stakeholders' needs. 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 7

Functional Requirements n Functional requirements break down the steps needed to meet the business requirement or requirements. Whereas a business requirement states the 'why' for a project, a functional requirement outlines the 'what'. For example, if the business requirement is to create a member directory for a trade association, the 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 8

functional requirements will outline who has access to the directory, how member register with the directory, who will have ownership of the data, what vehicle or vehicle will be used such as a website or paper-based directory, and so on. n When developing functional requirements, a comprehensive list of steps that will be taken during the project is developed. n 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 9

n Functional requirements are very detailed and provide information on how business needs and goals will be delivered through a specific project. While senior managers will be more interested in business requirements, functional requirements are generally what staff and lower-level 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 10

n managers need to focus on when developing a project. The end objective is for each step to contribute towards achieving the business requirement or requirements. It should also be clear who will be responsible for each step. 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 11

Types of System requirements : A-Functional requirements ¨ are the main things that the user expects from the software for example if the application is a banking application that application should be able to create a new account, update the account, delete an account, etc. functional requirements are detailed and are specified in the system design.

¨ Statements of services the system (SW) should provide, how the system should react to particular inputs and how the system should behave in particular situations. ¨ These are the functions that the users will be looking for in the software. ¨ defines a function of a system or its component. A function is described as a set of inputs, the behaviour, and outputs. 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 13

¨ May state what the system should not do. ¨ The functional requirement of an office productivity software should have the ability to calculate information from different sources and print them. 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 14

B-Non-functional requirements n n type of requirement that does not require actions. One example is the type of interface you should be expecting in a software. Other examples are security, accuracy, availability, capacity, reliability, and response time. These are basically the properties and performance expected from the software.

Domain requirements n The system's operational domain imposes requirements on the system. n Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable. 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 16

Requirements sources n n n n n Form-based specifications Definition of the function or entity using the form. Description of inputs and where they come from. Description of outputs and where they go to. Problems of requirements elicitation Stakeholders don’t know what they really want. Stakeholders express requirements in their own terms. Different stakeholders may have conflicting requirements. The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

Traditional Methods for Determining Requirements Interviewing individuals n Interviewing groups n Observing workers n Studying business documents n Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 18

1 - Interviewing individuals (domain expert) n n n Dialogue with user or manager to obtain their requirements Formal or informal interviews with stakeholders are part of most requirement elicitation processes. Types of interview ¨ ¨ n Closed interviews based on pre-determined list of questions Open interviews where various issues are explored with stakeholders. Effective interviewing Be open-minded, avoid pre-conceived ideas about the requirements be willing to listen to stakeholders. ¨ Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system. ¨

n n n Normally a mix of closed and open-ended interviewing. Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. Disadvantages ¨ Contradictions and inconsistencies between interviewees ¨ Follow-up discussions are time consuming

Guidelines for Effective Interviewing n Plan the interview. ¨ Prepare interviewee: appointment, priming questions. ¨ Prepare agenda, checklist, questions. n n Listen carefully and take notes (tape record if permitted). Review notes within 48 hours. Be neutral. Seek diverse views. Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 21

Choosing Interview Questions n Each question in an interview guide can include both verbal and non-verbal information. ¨ Open-ended questions: questions that have no prespecified answers ¨ Closed-ended questions: questions that ask those responding to choose from among a set of specified responses Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 22

Interviewing Guidelines n n n Don’t phrase a question in a way that implies a right or wrong answer. Listen very carefully. Type interview notes within 48 hours after the interview. Don’t set expectations about the new system unless you know these will be deliverables. Seek a variety of perspectives from the interviews. Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 23

2 -Interviewing Groups n Drawbacks to individual interviews: Contradictions and inconsistencies between interviewees ¨ Follow-up discussions are time consuming ¨ New interviews may reveal new questions that require additional interviews with those interviewed earlier ¨ Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 24

Interviewing groups (cont) n n n A facilitated process that supports idea generation by groups of customers. (brain storming) [Interview several key people together] Process ¨ Members come together as a group, but initially work separately. ¨ Each person writes ideas. ¨ Facilitator reads ideas out loud, and they are written on blackboard. ¨ Group discusses the ideas. ¨ Ideas are prioritized, combined, selected, reduced. Advantages ¨ More effective use of time ¨ Can hear agreements and disagreements at once ¨ Opportunity for synergies( )ﺗﻌﺎﻭﻥ Disadvantages More difficult to schedule than individual interviews

Nominal Group Technique (NGT) n n A facilitated process that supports idea generation by groups Process ¨ ¨ ¨ n Members come together as a group, but initially work separately. Each person writes ideas. Facilitator reads ideas out loud, and they are written on a blackboard or flipchart. Group openly discusses the ideas for clarification. Ideas are prioritized, combined, selected, reduced. Used to complement group meetings or as part of JAD effort Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 26

Directly Observing Users n Direct Observation Watching users do their jobs ¨ Used to obtain more firsthand objective measures of employee interaction with information systems ¨ Can cause people to change their normal operating behavior ¨ Time-consuming and limited time to observe ¨ Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 27

Analyzing Procedures and Other Documents n Document Analysis ¨ Review of existing business documents ¨ Can give a historical and “formal” view of system requirements. ¨ Types of documents: (get a copy of each) 1 - Forms (for data gathering and reports) 2 - Organization policy and regulations 3 - Organizational Chart Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 28

Analyzing Procedures and Other Documents (Cont. ) n Types of information to be discovered: ¨ Problems with existing system ¨ Opportunity to meet new need ¨ Organizational direction ¨ Names of key individuals ¨ Values of organization ¨ Special information processing circumstances ¨ Reasons for current system design ¨ Rules for processing data Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 29

Analyzing Procedures and Other Documents (Cont. ) n Useful document: Written work procedure ¨ For an individual or work group ¨ Describes how a particular job or task is performed ¨ Includes data and information used and created in the process Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 30

Analyzing Procedures and Other Documents (Cont. ) n Potential Problems with Procedure Documents: ¨ May involve duplication of effort ¨ May have missing procedures ¨ May be out of date ¨ May contradict information obtained through interviews Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 31

Analyzing Procedures and Other Documents (Cont. ) Formal Systems: the official way a system works as described in organizational documentation (i. e. work procedure) n Informal Systems: the way a system actually works (i. e. interviews, observations) n Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 32

Analyzing Procedures and Other Documents (Cont. ) n Useful document: Business form ¨ Used for all types of business functions ¨ Explicitly indicates what data flow in and out of a system and data necessary for the system to function ¨ Gives crucial information about the nature of the organization Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 33

Analyzing Procedures and Other Documents (Cont. ) n Useful document: Report ¨ Primary output of current system ¨ Enables you to work backwards from the report to the data needed to generate it n Useful document: Description of current information system Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 34

II - Modern Methods for Determining Requirements 1 - Joint Application Design (JAD) Brings together key users, managers, and systems analysts and Information System Staff. n collect system requirements simultaneously from key people n Objective s are to: 1 - analyze the existing system 2 - obtain user input and expectations 3 - document user requirements for the new system n

Joint Application Development v n n 36 JAD Participants and Roles Conducted off-site Team members meet in isolation for an extended period of time to collect system requirements simultaneously from key people. ¨ JAD participants should be insulated from the distraction of day-to-day operations

3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 37

End Result Documentation detailing existing system Features of proposed system[system requirements and specifications] 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 38

Joint Application Development v JAD Advantages and Disadvantages ¨Advantages 1 -Allows key users to participate effectively increase productivity 2 -more accurate statement of system requirements thus decreasing errors. 3 -a better understanding of common goals 4 -a stronger commitment to the success of the new system ¨ Disadvantages n More expensive and can be cumbersome if the group is too large relative to the size of the project 39

Contemporary Methods for Determining System Requirements n Chapter 6 Supporting JAD with GSS ¨ Facilitate sharing of ideas and voicing of opinions about system requirements ¨ Group support systems (GSS) can be used to enable more participation by group members in JAD ¨ Members type their answers into the computer ¨ All members of the group see what other members have been typing Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 40

Contemporary Methods for Determining System Requirements (Cont. ) n System prototypes ¨ Iterative development process ¨ Rudimentary working version of system is built ¨ Refine understanding of system requirements in concrete terms Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 41

Using Prototyping During Requirements Determination n Quickly converts requirements to working version of system n Once the user sees requirements converted to system, will ask for modifications or will generate additional requests Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 42

Using Prototyping During Requirements Determination (Cont. ) Figure 6 -7 The prototyping methodology (Source: Based on “Prototyping: The New Paradigm for Systems Development, ” by J. D. Naumann and A. M. Jenkins, MIS Quarterly 6(3): 29– 44. ) Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 43

Using Prototyping During Requirements Determination (Cont. ) n Most useful when: ¨ User requests are not clear. ¨ Few users are involved in the system. ¨ Designs are complex and require concrete form. ¨ There is a history of communication problems between analysts and users. ¨ Tools are readily available to build prototype. Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 44

Using Prototyping During Requirements Determination (Cont. ) n Drawbacks ¨ Tendency to avoid formal documentation ¨ Difficult to adapt to more general user audience ¨ Sharing data with other systems is often not considered ¨ Systems Development Life Cycle (SDLC) checks are often bypassed Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 45

3 - Business Process Reengineering (BPR) The fundamental rethinking and radical redesign of core business processes to achieve dramatic improvements in critical performance measures such as quality, cost, and service and speed. To achieve breakthrough improvements in products and services. BPR involves innovation: Creating new products and services, BPR is the process of changing the way we do our work so we do it better to accomplish the goals of our business. .

BPR(cont) n Goals ¨ Reorganize complete flow of data in major sections of an organization ¨ Eliminate unnecessary steps by combining them. ¨ Become more responsive to future change n Identification of processes to reengineer ¨ Key business processes n Set of activities designed to produce specific output for a particular customer or market n Focused on customers and outcome

Definition of Process n A process is simply a structured, measured set of activities designed to produce a specific output for a particular customers or market. -- Thomas Davenport n Characteristics: ¨ ¨ ¨ A specific sequencing of work activities across time and place A beginning and an end Clearly defined inputs and outputs Customer-focus How the work is done Measurable and meaningful performance

BPR Examples Bill payments method (phone, water, electricity…etc) n Tuition payments n ﺑﺮﺍﺀﺓ ﺍﻟﺬﻣﺔ n Selling, buying (e_business) n Internal correspondence ( )ﺍﻟﻤﺮﺍﺳﻼﺕ ﺍﻟﺪﺍﺧﻠﻴﺔ using email. n

4 -Disruptive Technologies n Disruptive technologies are technologies that enable the n breaking of long-held business rules that prevent organizations from making radical business changes. A disruptive technology is one that displaces an established technology and shakes up the industry or a ground-breaking product that creates a completely new industry. Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 50

Here a few examples of disruptive technologies: n n The personal computer (PC) displaced the typewriter and forever changed the way we work and communicate. Email : transformed the way we communicating, largely displacing letter-writing and disrupting the postal and greeting card industries. Cell phones: made it possible for people to call each other anywhere and disrupted the land telephone industry. The laptop computer and Mobile computing made a mobile workforce possible and made it possible for people to connect to corporate networks and collaborate from anywhere. In many organizations, laptops replaced desktops. 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 51

n n Cloud computing has been a hugely disruptive technology in the business world, displacing many resources that would have been located in -house or provided as a traditionally hosted service. Social networking has had a major impact on the way we communicate and -- especially for personal use -- has disrupted telephone, email, instant messaging and event planning. 3/16/2018 Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 52

Requirements Determination using Agile Methodologies n Continual user involvement ¨ Replace traditional SDLC waterfall with iterative analyze–design–code–test cycle n Agile usage-centered design ¨ Focuses on user goals, roles, and tasks n The Planning Game ¨ Based on e. Xtreme programming ¨ , Exploration( )ﺍﺳﺘﻜﺸﺎﻑ steering( , )ﺗﻮﺟﻴﻪ commitment Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 53

Continual User Involvement FIGURE 6 -9 The iterative analysis–design–code–test cycle Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 54

Agile Usage-Centered Design Steps n n n n Gather group of programmers, analysts, users, testers, facilitator. Document complaints of current system from customers Determine important user roles. Determine, prioritize, and describe tasks for each user role. Group similar tasks into interaction contexts. Associate each interaction context with a user interface for the system, and prototype the interaction context. Step through and modify the prototype. Chapter 6 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall 55

Requirements validation Concerned with demonstrating that the requirements define the system that the customer really wants. Reduce requirements error costs. ¨ Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error. ¨ n n n Requirements checking Validity. Does the system provide the functions which best support the customer’s needs? Consistency. Are there any requirements conflicts? Completeness. Are all functions required by the customer included? Realism. Can the requirements be implemented given available budget and technology Verifiability. Can the requirements be checked?

n n Requirements validation techniques Requirements reviews ¨ Systematic manual analysis of the requirements. [system analyst and customers discuss the requirements] n n n Prototyping Using an executable model of the system to check requirements. Test-case generation ¨ Developing tests for requirements to check testability.

n n Requirements management is the process of managing changing requirements during the requirements engineering process and system development. New requirements emerge as a system is being developed and after it has gone into use. You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements.

Changing requirements n n The business and technical environment of the system always changes after installation. What causes requirements to change? New hardware may be introduced. it may be necessary to interface the system with other systems, business priorities may change. ¨ new legislation and regulations may be introduced that the system must necessarily abide by. ¨ ¨ n Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory.