CS302: Software Engineering

4a. Identify different types of software requirements and data types

• Why are we interested in data?
• What are some of the properties of data that are relevant to a software development project?
• What are some different types of software requirements?
• How do we decide whether or not to perform a project, phase, activity, or task "in-house" or to outsource?
• How do we decide to whom a project, phase, activity, or task is assigned or awarded to a vendor?

Data types are gathered and analyzed in each development phase to build models. Software engineers collect data about the problem or task at hand. From this data, they specify the information that is needed to solve the problem or perform the task. In addition, they identify the relevant relationships that apply to this information. The resulting data description is a Problem Domain Model, the first SDLC model. This results in the software model requirements specification and builds models for the following SDLC phases. Each model will evolve due to changes, corrections, and improvements as development progresses. 

In the requirements phase, additional information on what is needed is elicited from stakeholders and used with the Problem Domain Model to describe a Requirements Model. In the Design Phase, additional information on processing the data is gathered and used with the Requirements Model and Problem Domain Model to describe a Design Model. The transition from the problem ('what" the problem or task is) to a solution ('how" to solve the problem or the task performed) occurs in the Design Phase. In the Implementation Phase, additional information on the details of the data and how it is processed is gathered and used with the previous models to create the software that solves the problem or performs the needed task. Thus, a data trail guides us in transforming the initial problem domain into a solution model. 

Several properties of data help build the project data models, including the period of the data, its structure, completeness, ambiguity, semantics, volume, privacy, and security. These properties are important considerations in building each of the phase data models. 

We classify software requirements according to various types. Generally, a requirement may be a technical or management requirement. A technical requirement pertains to the development products and the artifacts delivered to the customer or client, including requirements, design, implementation, test, and final system. A management requirement pertains to management control and monitoring of schedule, cost, functionality, quality, and configuration. Name the other types of requirements. 

You probably have been assuming that a software engineering team will develop a software system for a customer or client. While that is the normal role of the team, there are occasions where the team is the customer, and the desired system is outsourced. At the project, phase, activity, or task level, a feasibility study may result in a recommendation to outsource a part or even the entire project. Reasons for outsourcing include lower cost, lack of time or resources, lack of expertise or experience, a company strategic decision, or contract negotiations with a customer. We send a Request for Proposals (RFP) to identify a vendor or subcontractor. Data on the vendor is requested in the RFP and submitted with the vendor proposal. Instead of gathering data, the project is now a data provider to vendor or subcontractor companies. The data types and collection techniques presented in this unit now apply to the vendor or subcontractor. The project now has a different, passive role. 

The assignment of software activities and tasks is consistent with the principles of efficiency and effectiveness. Increasing specialization and availability of open-source subsystems and application libraries means that software purchasing and subcontracting occur more frequently. Once proposals from vendors or subcontractors are received, the project again gathers data, some of which will come from external sources, including the vendor. All of the considerations you have been studying apply application types, data properties, data gathering techniques, professionalism, and ethics. Data accuracy on qualifications, potential misuse of confidential or proprietary information, and potential conflicts of interest are of concern when dealing with vendors and subcontractors. 

To review, see:

• Data Gathering for Application Development
• Writing Software Requirements
• Object-Oriented Analysis

4b. Describe data/requirements gathering techniques used by software engineers

• How do we gather data?
• How do we verify and validate the data?
• What tools are available to support data gathering?

We gather data in each phase of the life-cycle. It is a primary activity in the requirements phase, called requirements gathering in that phase. We gather data from project and company documents, software artifacts, stakeholders, and external sources. 

Depending on the source, data gathered may be ambiguous and subject to interpretation, bias, incomplete, and incorrect. Verification pertains to correctness, while validation pertains to agreement or approval by significant stakeholders. We can corroborate data using multiple internal and external sources, different collection techniques (such as interviews, reviews, documents, and approvals), and different dates or times. Getting multiple sources for the same information is called triangulation.

Generic tools like document or spreadsheet software can support meetings, interviews, and reviews. Management software, in particular configuration management software, may be applicable. We can use software and system requirements engineering tools. Additionally, assessment software tools and documents (model-based assessment for software process improvement, such as CMMI (Capability Maturity Model for Process Improvement) are applicable since they use the same techniques we have discussed. Such is the nature of real problem-domain modeling. 

In later phases in the SDLC, when the transition occurs from the Problem domain to the Solution domain, techniques become more systematic, and special tools become available. As new data analysis, unstructured data, Big Data, and AI tools mature, support will "move" up the abstraction hierarchy – from implementation to design to requirements to problem domain. For example, MAXQDA is an older tool (1989), improved and updated to an AI-assist tool that supports management, transcription, coding, and analysis of interviews, meetings, questionnaire data, and visualization of the results.

To review, see Data Collection Techniques and Data Gathering Techniques for Each Application Type.

4c. 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)

• What are the strengths and weaknesses of data-gathering techniques?
• Which techniques are more efficient or effective for a phase activity?
• Why are professionalism and ethics important for data gathering?

Data characterizes properties (or "dimensions"), and we can use various data-gathering techniques to collect that data. We can use any technique, but we would like to use the most effective and efficient techniques for our application for a given data type. To identify the "best" techniques, we must understand the properties of the data, the strengths and weaknesses of each technique, and the type of data associated with our application. If we understand an application, we will know some of the properties of the data. As we gather data, we will learn more about the data. If we understand the strengths/weaknesses of the techniques, we can select the technique that will be best for our application's data. 

Data gathering and data collection techniques can put a software engineer in situations that put the rights of confidentiality, privacy, and ownership of stakeholders and organizations at risk. Suppose you were a participant in a group interview, and one of the other interviewees revealed what you said to project team members who were not in the interview. No matter what you said in the interview, its revelation could inhibit open discussion in future interviews, resulting in incomplete data. Moreover, what you said in the interview could create a negative impression of you or others in the project. 

To review, see Data Collection Techniques and Data Gathering Techniques for Each Application Type.

Unit 4 Vocabulary

This vocabulary list includes terms you must know to complete the final exam successfully.

• data types
• Request for Proposals (RFP)
• requirements gathering
• requirements phase
• triangulation
• validation
• verification