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

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

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

    • 4.3: Data Collection Techniques for Each Application Type

    • Unit 4 Assessment

      • Receive a grade