Requirements Modeling

Requirements Modeling
PHASE 2: SYSTEMS ANALYSIS Chapter 3 Requirements Modeling

Phase Description Systems analysis is the second of five phases in the systems development life cycle (SDLC) Uses requirements modeling and data and process modeling to represent the new system Before proceeding to the next phase, systems design, you will consider system development strategies

Chapter Objectives Describe systems analysis phase activities and the end product of the systems analysis phase Explain joint application development (JAD) and rapid application development (RAD) Understand how systems analysts use a functional decomposition diagram (FDD) Describe the Unified Modeling Language (UML) and explain use case diagrams and sequence diagrams 3

Chapter Objectives List and describe system requirements, including outputs, inputs, processes, performance, and controls Explain the importance of scalability in system design Use fact-finding techniques, including interviews, documentation review, observation, questionnaires, sampling, and research 3

Chapter Objectives Define total cost of ownership (TCO) and explain the concept Conduct a successful interview Develop effective documentation methods to use during systems development

Introduction This chapter describes requirements modeling techniques and team-based methods that systems analysts use to visualize and document new systems The chapter then discusses system requirements and fact-finding techniques, which include interviewing, documentation review, observation, surveys and questionnaires, sampling, and research 4

Systems Analysis Phase Overview
The overall objective is to understand the proposed project, ensure that it will support business requirements, and build a solid foundation for system development You use models and other documentation tools to visualize and describe the proposed system

Systems Analysis Activities Requirements modeling Outputs Inputs Processes Performance Security Data and process modeling Development Strategies System requirements document Requirements modeling: Fact-finding we do to describe our current system Outputs – electronic or printed produced by system Inputs – necessary data that enters system manually or automated Processes – Logical rules to transform data Performance – system characteristics like speed, capacity, availability Security – all the hardware, software and procedures in place to protect system Data and process modeling In data and process modeling we will continue the modeling process by learning how to represent system data and processes graphically using traditional structured analysis techniques. This is in Chapter 4. Whereas structured analysis treats these processes and data as separate components, object-oriented analysis (OOA) combines data and processes that act on data into things called objects (as one). We will cover that later in the course in ToolKit 5. System Requirement: Each phase of the SDLC has an end product or deliverable. The deliverable for the Systems Analysis phase is the Systems Requirement Document. This document is an overall design for our new system Development Strategies: In Chapter 5, Development Strategies, we will look at development options and prepare for the transition to the systems design phase of the SDLC. Basically, we will come up with the alternative options for the system and then make a recommendation to management.

Systems Analysis Skills Analytical skills Interpersonal skills Team-Oriented Methods and Techniques Joint application development (JAD) Rapid application development (RAD) JAD (Joint Application Development) A team-oriented technique for fact-finding and requirements modeling. Systems developers use JAD whenever group input and interaction is needed. RAD (Rapid Application Development) A condensed version of the entire SDLC, with users involved every step of the way. While JAD focuses on fact-finding and requirements determination, RAD is on a fast-track to get the system planned, designed, constructed and implemented.

Joint Application Development
User Involvement Users have a vital stake in an information system, and they should participate fully Successful systems must be user-oriented and users need to be involved User Involvement Until recently, the IT staff would hand a system to the users and say here you go, take it or leave it. And guess what, a lot of times the system would be left. Now, the users take part in development and therefore, own it.

JAD Participants and Roles JAD participants should be insulated from the distraction of day-to-day operations Objective is to analyze the existing system, obtain user input and expectations, and document user requirements for the new system

JAD Advantages and Disadvantages Advantages Allows key users to participate effectively When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system Disadvantages More expensive and can be cumbersome if the group is too large relative to the size of the project

Rapid Application Development
Rapid application development (RAD) is a team-based technique that speeds up information systems development and produces a functioning information system RAD uses a group approach, but goes much further The end product of RAD is the new information system

RAD Phases and Activities Now keep in mind that RAD is a type of SDLC that has been condensed. So in this course, we are walking you through all the phases of the SDLC, the RAD is a quick version of that. The RAD model consists of 4 phases: requirements planning, user design, construction, and cutover. Requirements Planning: Combines elements of the Systems Planning and Systems Analysis phases of the SDLC. Project Scope, constraints, and system requirements are hammered out by IT, users, and managers. User Design: Users and analysts interact to develop models and prototypes that represent all system processes, outputs and inputs. JAD and CASE tools are used to go through this process. Models are approved. Construction: Focus is on program and application development similar to the SDLC. However, users continue to participate and suggest changes or improvements as screens and reports are developed. Cutover: Like final implementation in SDLC including data conversion, testing, changeover to new system and user training.

RAD Objectives To cut development time and expense by involving the users in every phase of systems development Successful RAD team must have IT resources, skills, and management support Helps a development team design a system that requires a highly interactive or complex user interface

RAD Advantages and Disadvantages Advantages Systems can be developed more quickly with significant cost savings Disadvantages RAD stresses the mechanics of the system itself and does not emphasize the company’s strategic business needs Might allow less time to develop quality, consistency, and design standards

Modeling Tools and Techniques
CASE Tools Offer powerful modeling features Systems analysts use modeling and fact-finding interactively Functional Decomposition Diagrams Functional decomposition diagram (FDD) Let’s look at the tools and techniques that we will use in the SDLC’s Analysis Phase: CASE Tools: Computer Aided Software Engineering First of all, not every IT department can afford CASE tools. Examples: Rational Rose, Erwin They offer features for all to some of the phases of the SDLC. Functional Decomposition Diagrams: or a Structure Chart A top down representation of a function or process. An analyst can show business functions and break them down into lower-level functions and processes. Similar to creating an org chart in that you start at the top and work your way down. Do an example:

Modeling Tools and Techniques
Unified Modeling Language (UML) Provides various graphical tools Use case diagrams Actor Sequence diagrams Unified Modeling Language  A method of documenting software systems design. It uses object-oriented design concepts, but is independent of any specific programming language. Use Case Diagrams  When the users and analysts are working on modeling system functions during analysis, the use case diagram visually represent the interaction between the user and the system. Actor  The user becomes an actor, with a role that describes how he/she interacts with the system. Sequence Diagram  A sequence diagram shows the timing of interactions between objects as they occur. For example, if we were showing the Maryville registration process it may show from top to bottom all of the classes that are in a Maryville system (i.e. Student, Registrar) and the messages that go back and forth between those.

System Requirements Checklist
Five general categories Outputs Inputs Processes Performance Controls System Requirement: - A characteristic or feature that must be included in an information system to satisfy the business requirements and be acceptable to users. They serve as benchmarks to measure the acceptability of the finished system. Did we meet system requirements? You can have bare bones, or bells and whistles. Because resources usually are limited, systems requirements often are prioritized. Some analysts divide system requirements into two types: functional requirements and technical requirements. Functional requirements describe activities or processes the system must perform (e.g., calculate payroll taxes). Technical requirements describe an operating environment or performance objective (e.g., must run with Windows NT or must have one-half second response time).

Outputs  Example Requirements The Web site must report online volume statistics every four hours, and hourly during peak periods The inventory system must produce a daily report showing the part number, description, quantity on hand, quantity allocated, quantity available, and unit cost of all parts — sorted by part number

Inputs  Example Requirements Manufacturing employees must swipe their ID cards into online data collection terminals that record labor costs and calculate production efficiency The department head must enter overtime hours on a separate screen

Processes  Example Requirements The student records system must calculate the GPA at the end of each semester As the final step in year-end processing, the payroll system must update employee salaries, bonuses, and benefits and produce tax data required by the IRS

Performance  Example Requirements The system must support 25 users online simultaneously Response time must not exceed four seconds

Controls  Example Requirements The system must provide log-on security at the operating system level and at the application level An employee record must be added, changed, or deleted only by a member of the human resources department

Future Growth, Costs, and Benefits
Scalability A scalable system offers a better return on the initial investment To evaluate, you need information about projected future volume for all outputs, inputs, and processes Scalability: The system’s ability to handle increased business volume and transactions in the future. - Because it has a longer useful life, better ROI To evaluate  info on future volume Example: Our data warehouse, how many users, how many hits, periods of peak activity, types of reports and data items, storage, how long, response time we needed, time perform ETL to go live with data. Data storage is an important scalability issue because you need to predict not only current needs but future needs based on system activity and growth. These requirements affect h/w, s/w, bandwidth. Consider data retention, archival.

Future Growth, Costs, and Benefits
Total Cost of Ownership Total cost of ownership (TCO) is especially important if the development team is evaluating several alternatives One problem is that cost estimates tend to understate indirect costs Rapid Economic Justification (REJ) TCO involves direct and indirect costs associated with development and ownership of the system. Indirect Costs  user support, down time productivity losses (not always apparent) Example: Purchase  Used car. Direct costs are purchase price. Indirect costs are registration fees, insurance, gasoline, maintenance and repair, and so on. Evaluation of Alternatives: requires that you look at all costs to compare apples to apples when making a recommendation to management. Estimates: Even if the accurate figures are unavailable, especially on indirect costs, still try to identify and include them in TCO estimates. REJ: Developed by Microsoft. A framework to help IT folks analyze and optimize IT investments. Primary emphasis is on business improvement, rather than operational efficiency.

Fact-Finding Fact-Finding Overview
The first step is to identify the information you need Who, What, Where, When, How, and Why? Difference between asking what is being done and what could or should be done The Zachman Framework Zachman Framework for Enterprise Architecture Now we move into fact-finding: Software can help you gather and analyze facts but no program does the fact-find work for you. 1) Identify the info you need. 2) Ask: What business functions are supported by the current system? What, strategic goals, business requirements are supported by the system? What info do users and managers need from the system? Who, What, Where, When, How, and Why? Who?  Who does the work/procedures? Could others do it better? What?  What is being done? What procedures are followed? Why is it necessary? Can it be changed? Where?  Where are operations performed? Whey? Could they be performed elsewhere more efficiently? When?  When is a procedure performed? Why then? Is this the best time? How?  How is a procedure performed? Why in this manner? Could it be done better, more efficiently, less expensively, in some other manner? Zachman Framework: In the 1980s John Zachman suggested that the ideas of how industries such as architecture and contruction handled complex projects could be applied to systems development. Zachman Framework for Enterprise Architecture is a model that asks fact-finding questions in a systems development context. It helps managers and users understand the model and assures that overall business goals translate to successful IT projects.

Interviews Systems analysts spend a great deal of time talking with people Much of that time is spent conducting interviews

Interview Step 1: Determine the People to Interview
Informal structure Step 2: Establish Objectives for the Interview Determine the general areas to be discussed List the facts you want to gather People to Interview: You can refer to the formal org charts but also talk to people to find out who really knows the system functionality and work assignments. If you don’t know personally, ask around.

Interviews Step 3: Develop Interview Questions
Creating a standard list of interview questions helps to keep you on track and avoid unnecessary tangents Avoid leading questions Open-ended questions Closed-ended questions Range-of-response questions

Interviews Step 4: Prepare for the Interview
Careful preparation is essential because an interview is an important meeting and not just a casual chat Limit the interview to no more than one hour Send a list of topics Ask the interviewee to have samples available Limit time: This is an interruption to the interviewee. Be considerate Send topic list: Especially if you need detailed info. This way interviewee can be prepared and minimize need for follow-up meeting. Samples: Includes the list of samples you need so they are available for you. Location: Some believe that they should take place in interviewee’s office, others feel a neutral location is better. An argument for interviewee’s office is make them feel more comfortable and they have access to materials they might need during discussion. On other hand, interruptions can be a problem.

Interviews Step 5: Conduct the Interview
Develop a specific plan for the meeting Begin by introducing yourself, describing the project, and explaining interview objectives Use engaged listening Allow the person enough time to think about the question Summarize main points After interview, summarize the session and seek a confirmation Establishing a rapport with the interviewee is important. Engaged listening: Listen carefully to the answers, don’t hear only what you expect to hear, concentrate on what is said and notice nonverbal communication. Enough Time: Studies show maximum pause during a conversation is usually 3-5 seconds. Wait patiently. Summarize and explain next course of action. Perhaps you’ll send follow-up memo or schedule higher-level meeting, or interviewee will get back with you.

Interviews Step 6: Document the Interview
During the interview, note taking should be kept to a minimum After the interview, but still in office, record the information quickly After the interview, having left office, send memo expressing appreciation, including the main points discussed so the interviewee has a written summary and can offer additions or corrections Notes: If possible, jot notes while looking at the person. After Interview, while still in office: Don’t write down too much then either. Just a few to do’s and reminders. After Interview, left office: Record information so you don’t forget. Studies show that 50% of a conversation is forgotten within 30 minutes. Tape recorders can be effective tools but many people feel uncomfortable. Get approval first and assure user you will erase tape after transcribing notes and stop and rewind tape at anytime during interview or even turn it off for a sensitive question. But even with a tape recorder, you should listen carefully. Send memo expressing appreciation to interviewee including written summary.

Interviews Step 7: Evaluate the Interview Unsuccessful Interviews
In addition to recording the facts obtained in an interview, try to identify any possible biases Unsuccessful Interviews No matter how well you prepare for interviews, some are not successful Biases: Examples  an interviewee who is protecting his or her own territory might give incomplete answers or not volunteer information.  an interviewee with strong opinions about current or future system might distort facts. Unsuccessful Interviews: - Personality conflict or misunderstanding could negatively affect interview. - Interviewee may be afraid system will eliminate his/her job. - Interviewee may give short/incomplete answers to open-ended questions. Switch to closed-ended questions. If doesn’t help, find tactful way to end. - If you absolutely need info from this person, have another analyst try to interview them.

Other Fact-Finding Techniques
Document Review Observation Seeing the system in action gives you additional perspective and a better understanding of the system procedures Plan your observations in advance Hawthorne Effect Document Review: - Make sure when you are reviewing documents that they are up to date. The types of documents you could review are procedures, forms, reports, documentation from the old/current system, screen shots. Observation: See system in action You may find that neither the interviews nor the documentation were accurate. You can build relationships with the users if they know that you really do care about their system and what they do. Plan observations Prepare a checklist of tasks you want to observe and questions you want to ask: 1) Identify method of handling situations not covered by standard operating procedures. Example: Payroll System  If employee loses time card, If employee starts shift 10 min late but works 20 min. OT 2) Observe all steps in a transaction and note documents, inputs, outputs, and processes involved. 3) Examine each form, record, report and purpose for each 4) For each user you observe  what info do they receive from others, generate? How is info communicated? 5) Talk to people who receive reports complete? timely? accurate? useful? info eliminated or improved? Hawthorne Effect: Productivity from workers observed improves whether conditions were made better or worse.

Questionnaires and Surveys When designing a questionnaire, the most important rule of all is to make sure that your questions collect the right data in a form that you can use to further your fact-finding Fill-in form Most important thing of all  make sure your questions collect the right data Should questionnaire by anonymous?  do you need to know? 1) Does analyst need to know who respondents are in order to match or correlate information? Example: % of users need a certain s/w feature but specific user names might not be relevant. 2) Does questionnaire include sensitive or controversial topics? Many people do not want to be identified when answering a question like “How well has your supervisor explain the system to you? Keep questionnaire brief Provide clear instructions Arrange questions in logical order, simple to complex Do not lead response or give clues to expected answers Limit use of open-ended questions, difficult to tabulate Limit use of questions that raise concerns about job security or negative issues Include general comments section Test questionnaire on small test group if possible before sending to large group

Sampling Systematic sample Stratified sample Random sample Main objective of a sample is to ensure that it represents the overall population accurately Sampling When studying an information system, you should collect examples of actual documents suing a process called sampling. Samples could include records, reports, operational logs, data entry documents, complaint summaries, work requests, and forms. Examples: Suppose you have a list of 200 customers who complained about errors on their statements and you want to review a representative sample of 20 customers. Systematic A systematic sample would select every 10th customer for review. Stratified Select a sample from categories and select a random set from that category. It ensures the sample is balanced geographically. We could select 5 customers from each of 4 zip codes for a total of 20 employees. Random Selects any 20 customers Examples of how you might use sampling could be if you are looking at inventory transactions. You should select a sample of transactions typical of actual inventory operations. Do not include unusual or unrelated examples. For instance, if a company performs special process on the last business day of the month, don’t pick that day to sample daily operations. Also, use sampling when considering who to use for interviews or questionnaires.

Research Newsgroups Site visit Research can include Internet, IT magazines, and books to get background information, technical material and new about industry trends and developments. Newsgroups Internet newsgroups are good resources for exchanging information with other professionals. Site Visit Schedule a site visit to another company if interested in a new s/w package. Get feedback from that company on its use (good and bad). Research Company Gartner Group offers info on s/w for a fee. Trade Magazines But can be biased

Interviews versus Questionnaires Interview is more familiar and personal Questionnaire gives many people the opportunity to provide input and suggestions Brainstorming Structured brainstorming Unstructured brainstorming Interview People unwilling to put critical or controversial comments in writing might talk more freely in person. You can read people’s reactions in face-to-face and ask follow-up questions. You can watch for clues to see if answers are knowledgeable and unbiased. Costly and time-consuming Questionnaire Can answer questions at own convenience May be able to be more candid if anonymous Good questionnaires require skill and time If question is misinterpreted, you can’t have a follow-up as in an interview Recipients can view as intrusive, time-consuming, impersonal Brainstorming Small group discussion of problem, opportunity, or issue. Encourages new ideas and enables participants to build on each other’s input and thoughts. Structured: Each participant speaks his/her turn or passes. Unstructured: Anyone can speak at any time. Results are recorded and made part of fact-find documentation process.

Documentation The Need for Recording the Facts
Record information as soon as you obtain it Use the simplest recording method Record your findings in such a way that they can be understood by someone else Organize your documentation

Documentation Software Tools CASE Tools Productivity Software
Word processing, spreadsheets, database management, presentation graphics, histogram

Documentation Software Tools Graphics modeling software - Visio
Personal information managers Personal information manager (PIM)  Outlook Handheld computers Personal digital assistants (PDAs) Wireless communication devices PDA Smart Phone

Preview of Data and Process Modeling
At the conclusion of requirements modeling, systems developers should have clear understanding of business processes and system requirements The next step is to construct a logical design of the system The systems analysis phase includes three activities: requirements modeling data and process modeling (Ch. 4) consideration of development strategies (Ch. 5)

Chapter Summary The main objective is to understand the proposed project and build a solid foundation for the systems design phase You identify the business-related requirements for the new information system, including outputs, inputs, processes, performance, and controls The fact-finding process includes interviewing, document review, observation, questionnaires, sampling, and research 49

Chapter Summary Any questions?
Systems analysts should carefully record and document factual information as it is collected, and various software tools can help an analyst visualize and describe an information system Any questions? 49

Requirements Modeling

Similar presentations

Presentation on theme: "Requirements Modeling"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Requirements Modeling

Similar presentations

Presentation on theme: "Requirements Modeling"— Presentation transcript:

Similar presentations

About project

Feedback