BIO PRESENTATION PAPER W15 September 29, 2004 3:00 PM D ISCOVERING THE T RUE S OFTWARE R EQUIREMENTS Paul Desantis Hughes Netw ork Systems Better Software Conference & EXPO September 27-30, 2004 San Jose, CA USA
Paul DeSantis Throughout Paul’s career, he has been involved in requirements analysis both formally and informally. This ranged from simple analysis of software enhancements to collecting requirements for a whole new product. Recently, he has become more involved in requirements management. His own hybrid requirements analysis based on academics helped him win Best Sales Team Win and Achievement awards and has been credited in making other sales. Paul has also performed many sales presentations to potentials clients in several different countries, taught an engineering seminar in and India, taught numerous internal classes on systems analysis, Unified Modeling Language, data-link protocol conversion techniques, and IBM System Network Architecture. As a volunteer, he spoke to Frederick County, Maryland public school students for National Engineers Week and taught merit badge courses at the Boy Scouts National Jamboree(s). Paul holds a B.S. in Engineering Technology and a M.S. in Technology Management. He has been employed with Hughes Network Systems for the past fifteen years.
Discovering the True Software Requirements Paul DeSantis 1HNS-32099 7/15/2004 Better Software Conference 2004
Presentation Objectives This paper discusses an academic approach to requirements analysis. Topics covered will be: • Brief overview of systems analysis • Understanding the stakeholders and their perspectives • Discovering requirements • Documenting and expressing requirements • Avoiding over analysis • Prioritizing requirements • Knowing requirements conflict • Defining open systems 2HNS-32099 7/15/2004 Better Software Conference 2004
What are Requirements and What Makes Them Important? • What are requirements? – This paper will simply define requirements as the needs of the stakeholders . One could also view requirements as solving problems. • What makes requirements important? – Mistakes made in the front end of the development life cycle can have substantially negative impacts on the system design’s total cost, time schedule, and customer satisfaction – It is the stakeholders’ needs that become the originating requirements—the business requirements. These originating requirements are major inputs for almost every design function (Buede, 2000). – This is why requirements are important, because they influence the entire development life cycle. 3HNS-32099 7/15/2004 Better Software Conference 2004
Overview of Systems Analysis • Scope Definition Phase – Answers the question, “Is it worth looking at this project?” – Deliverables: Brief Statement of Problem and Solution and Problem Statement Matrix – Tasks: Identify baseline problems and opportunities, Negotiate baseline scope, Assess baseline project worthiness, Develop baseline schedule and budget, Communicate the project plan • Problem Analysis Phase – Answers the question, “Are the problems really worth solving?” – Deliverables: Problems, Opportunities, Objectives and Constraints Matrix, a Cause and Effect Diagram, and PIECES worksheet – Tasks: Understand the problem domain, Analyze problems and opportunities, Analyze business processes, Establish system improvement objectives 4HNS-32099 7/15/2004 Better Software Conference 2004
Overview of Systems Analysis • Requirements Analysis Phase – Answers the question, “What do the users need and want from a new system?” – Deliverables: Use cases glossary, diagrams, and narratives – Tasks: Identify and express system requirements, Prioritize systems requirements • Logical Design Phase – Performs systems modeling or prototyping – Deliverables: A prototype of solution (product), or Unified Modeling Language (UML), data and process models – Tasks: Structure functional requirements, Prototype functional requirements, Validate functional requirements, Define acceptance test cases • Decision Analysis Phase – Identify options, analyze options, then sell best solution – Deliverables: Feasibility Analysis Matrix, System Proposal 5HNS-32099 7/15/2004 Better Software Conference 2004
Phase One Scope Definition • The scope definition phase assesses the project worthiness by answering, “Is it worth looking at this project?” To help assess, a problem statement matrix is used (Whitten, 2004). • Caution about builder-architected systems. Solutions for these systems are looking for a problem, making them vulnerable to working on the wrong problem (Maier, 2002). • Sample problem statement matrix: Brief Statements of Problem, Urgency Visibility Annual Benefits Priority or Rank Proposed Opportunity, or Solution Directive List of Time frame to What degree Dollar estimate Rating scale At this phase, statements solve would the (best guess) possible identifying the problem, solution be of savings or solutions problem, rating scale visible to increase in expressed in opportunity, or customers, revenue simple terms directive rating scale 6HNS-32099 7/15/2004 Better Software Conference 2004
Phase Two Problem Analysis Two artifacts completed in the problem analysis phase, which are used later, are the Problems, Opportunities, Objectives, and Constraints Matrix and the Performance, Information, Economics, Control, Efficiency and Service (PIECES) framework. Cause-and-Effect Analysis Systems Improvement Objectives Problem or Opportunity Causes and Effects System Objective System Constraints Problem statement Possible causes of the What you expect to Something that will problem, or the achieve reduce your flexibility symptoms in defining an improvement Performance Control (and security) A. Throughput A. Too little security or control B. Response B. Too much security or control Information (and data) Efficiency A. Outputs A. People, machines, or computers waste time B. Inputs B. People, machines, or computers waste materials and supplies C. Stored Data C. Effort required for tasks is excessive D. Material required for tasks is excessive Economics Service A. Costs A. System produces inaccurate results B. Profits B. System produces inconsistent results C. System is not easy to use D. System is incompatible with other systems 7HNS-32099 7/15/2004 Better Software Conference 2004
Phase Three Requirements Analysis Identifying the Stakeholders • One of the primary roles of Systems Analysis in the development of systems is to collect the needs from the stakeholders, and bridge communications gap between non-technical and technical stakeholders. Who are these stakeholders and what role do they perform? – System owners • These stakeholders are usually middle to executive level managers who are concerned about cost and value – Systems users • These stakeholders are concerned about getting the job done using the functionality of the system along with its ease of use and learning 8HNS-32099 7/15/2004 Better Software Conference 2004
Identifying the Stakeholders – Systems users (Cont.) • Internal (employees) • External (suppliers, customers) – System designers • Technical specialists who translate the business requirements into technical solutions by designing the various system components – System builders • Technical specialists who construct the system according to the system designer’s specifications 9HNS-32099 7/15/2004 Better Software Conference 2004
Understanding the Stakeholders and Their Perspectives • Stakeholders and their perspectives can be understood using building blocks for an information system. • Knowledge building blocks – System owners’ view of knowledge is to identify business entities and rules, and is interested in the information that adds new business knowledge about these entities and rules. – System users’ view of knowledge will provide data requirements, which are an extension of business entities and rules. Users are concerned about the details (attributes) of entities and rules. – System designers’ view of knowledge will translate the system users’ business data requirements into a database design. Their concern is with database technology and view of knowledge consists of data structures, fields, indexes, etc. – System builders’ view of knowledge will construct the actual database structure using tools and techniques (e.g., SQL), based on the designers’ ideas. 10HNS-32099 7/15/2004 Better Software Conference 2004
Understanding the Stakeholders and Their Perspectives • Process building blocks – System owners view processes in the form of business functions (sales, service, manufacturing, shipping, receiving, and accounting). These business functions can be described as many events and responses, e.g., • Event - Customer submits order. • Response - Shipping department ships order. – System users view processes as the work required to carry out the business function’s response to an event, in accordance with policy. – System designers view processes as determining which processes (work) can be automated and how best to automate them using available technology. – Systems builders view processes from the perspective of programming languages in order to build the application program. 11HNS-32099 7/15/2004 Better Software Conference 2004
Recommend
More recommend
