Unit 4: Software Requirements Gathering
Requirements gathering requires the software engineer (in this case, a business analyst) to interact with the stakeholders, including customers and users, to gather/collect information about what the software system being developed needs to do. There is also the situation where vendors are subcontracted to develop all or some components of the software systems or the hardware on which the software will run. In this case, the vendors bid on the subcontract by providing a proposal in response to a proposal request. In this unit, you will learn the data/information types, data collection techniques, and data collection and application types.
Requirements data elicitation and gathering tools are manual, for example, interviews, questionnaires, brainstorming meetings, and reviews. Automation potential consists of tools that help develop diagrams for modeling data, creating relevant UML data diagrams, such as entity relation diagrams and class diagrams, and process diagrams, such as collaboration and sequence diagrams. Since requirements data originates in the user application domain, requirements data encompasses spoken and written stories. Since requirements analysis transitions to the solution domains (the "what" and "how" domains), opportunities for software tool automation lie in support of the development of use cases, the identification of abstractions, tracing forward from related existing requirements and related problem domain elements, tracing backward from related products of the SDLC phases, from analysis of problem domain and solution domain data and processes, such as related software trouble reports and change requests, and tools that automate estimation and prediction, decision making, correlation of data, and inference of "new" data. Many of these tools will come from AI search, analysis, and learning tools.
Completing this unit should take you approximately 3 hours.
Upon successful completion of this unit, you will be able to:
- identify different types of software requirements and data types;
- describe data/requirements gathering techniques used by software engineers; and
- outline data gathering techniques, such as interviews, meetings, or observation, that are most useful for various application types, including transaction processing systems (TPS), decision support systems (DSS), and executive information systems (EIS).
4.1: What Are Requirements and Data Types?
Software requirements are goal specifications of cost, schedule, functionality, or quality that a software system development and resulting software product needs to satisfy. Typically, those goal statements are written using the word "shall". The specifications must be necessary and sufficient. "Necessary" means that each specification is needed to address a customer's need. "Sufficient" means that a specification is only included if it addresses a need of the customer, not a specification for a "want" that, if left out, does not affect the satisfaction of customer needs. In practice, requirements often contain nice-to-have and optional requirements, but these are singled out and treated accordingly. In general, requirements describe the problem to be solved and not the solution. However, problems can have multiple solutions, and the requirements must include only those that address customer needs and exclude those that do not. As with software, requirements have quality features such as necessary, sufficient, complete, verifiable, validatable, and measurable. In short, whereas architecture, design, and implementation answer the "what" and "how" of the solution, requirements definition answers the "why" and "what" of the problem.
There are many different data dimensions, such as time and volume. Each dimension is important in defining the requirements of applications. Read this section, which discusses these data types. Bear in mind how much and what type of information should be collected.
This article discusses the 2011 revisions to the IEEE 830 standard for requirements analysis. What are the phases of software requirement engineering?
Pay attention to the section on types of software requirements and the unique quality of each type. It is important to identify and include more than just the functional requirements to have a quality system.
This analysis emphasizes investigating and understanding the problem domain and requirements rather than a solution. Read the slides, which illustrate the use of UML in requirements analysis. Read this section to learn more about some of the terms and concepts related to requirements and their types. These terms can initially seem ambiguous, but we will quickly learn how they relate. A walkthrough of a requirements analysis product is provided, illustrating parts of the analysis using POST, a point-of-sale system.
4.2: Requirements and Data Gathering Techniques
This section describes the data types obtained from each data-gathering technique. These are summarized in a table that relates the technique to the type of data collected from the technique.
Data gathering is the interaction between the software engineer (a business analyst) and the customers (including users). There are many techniques for gathering data, including interviews, meetings, observations, questionnaires, and reviewing software, internal documents, and external documents. Data gathering is an activity where ethical and professional conduct issues typically arise, particularly regarding privacy, security, responsibility, accountability, and communication.
4.3: Data Collection Techniques for Each Application Type
Read this section and identify the data types needed by each application type. These are summarized in a table that relates application type to the type of data it needs. Using this table (application type/data type needed) and the previous table (data gathering technique – data type obtained), requirements stakeholders can select the most appropriate data gathering techniques. This is illustrated in the combined table that relates data gathering technique to application type.
Unit 4 Assessment
- Receive a grade
Take this assessment to see how well you understood this unit.
- This assessment does not count towards your grade. It is just for practice!
- You will see the correct answers when you submit your answers. Use this to help you study for the final exam!
- You can take this assessment as many times as you want, whenever you want.