Overview

After system engineering is completed, software engineers need to look at the role of software in the proposed system. Software requirements analysis is necessary to avoid creating a software product that fails to meet the customer's needs. Data, functional, and behavioral requirements are elicited from the customer and refined to create a specification that can be used to design the system. Software requirements work products must be reviewed for clarity, completeness, and consistency.

Requirements Analysis

• Software engineering task that bridges the gap between system level requirements engineering and software design.
• Provides software designer with a representation of system information, function, and behavior that can be translated to data, architectural, and component-level designs.
• Expect to do a little bit of design during analysis and a little bit of analysis during design.

Software Requirements Analysis Phases

• Problem recognition
• Evaluation and synthesis (focus is on what not how)
• Modeling
• Specification
• Review

Software Requirements Elicitation

• Customer meetings are the most commonly used technique.
• Use context free questions to find out customer's goals and benefits, identify stakeholders, gain understanding of problem, determine customer reactions to proposed solutions, and assess meeting effectiveness.
• If many users are involved, be certain that a representative cross section of users is interviewed.

Facilitated Action Specification Techniques (FAST)

• Meeting held at neutral site, attended by both software engineers and customers.
• Rules established for preparation and participation.
• Agenda suggested to cover important points and to allow for brainstorming.
• Meeting controlled by facilitator (customer, developer, or outsider).
• Definition mechanism (flip charts, stickers, electronic device, etc.) is used.
• Goal is to identify problem, propose elements of solution, negotiate different approaches, and specify a preliminary set of solution requirements.

Quality Function Deployment (QFD)

• Translates customer needs into technical software requirements.
• Uses customer interviews, observation, surveys, and historical data for requirements gathering.
• Customer voice table (contains summary of requirements)
• Normal requirements (must be present in product for customer to be satisfied)
• Expected requirements (things like ease of use or reliability of operation, that customer assumes will be present in a professionally developed product without having to request them explicitly)
• Exciting requirements (features that go beyond the customer's expectations and prove to be very satisfying when they are present)
• Function deployment (used during customer meetings to determine the value of each function required for system)
• Information deployment (identifies data objects and events produced and consumed by the system)
• Task deployment (examines the behavior of product within it environment)
• Value analysis (used to determine the relative priority of requirements during function, information, and task deployment)

Use-Cases

• Scenarios that describe how the product will be used in specific situations.
• Written narratives that describe the role of an actor (user or device) as interaction with the system occurs.
• Use-cases are designed from the actor's point of view.
• Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use-cases.

Analysis Principles

• The information domain of the problem must be represented and understood.
• The functions that the software is to perform must be defined.
• Software behavior must be represented.
• Models depicting information, function, and behavior must be partitioned in a hierarchical manner that uncovers detail.
• The analysis process should move from the essential information toward implementation detail.

Information Domain

• Encompasses all data objects that contain numbers, text, images, audio, or video.
• Information content or data model (shows the relationships among the data and control objects that make up the system)
• Information flow (represents the manner in which data and control objects change as each moves through the system)
• Information structure (representations of the internal organizations of various data and control items)

Modeling

• Data model (shows relationships among system objects)
• Functional model (description of the functions that enable the transformations of system objects)
• Behavioral model (manner in which software responds to events from the outside world)

Partitioning

• Process that results in the elaboration of data, function, or behavior.
• Horizontal partitioning is a breadth-first decomposition of the system function, behavior, or information, one level at a time.
• Vertical partitioning is a depth-first elaboration of the system function, behavior, or information, one subsytem at a time.

Software Requirements Views

• Essential view - presents the functions to be accomplished and the information to be processed without regard to implementation.
• Implementation view - presents the real world manifestation of processing functions and information structures.
• Avoid the temptation to move directly to the implementation view, assuming that the essence of the problem is obvious.

Software Prototyping

• Throwaway prototyping (prototype only used as a demonstration of product requirements, finished software is engineered using another paradigm)
• Evolutionary prototyping (prototype is refined to build the finished system)
• Customer resources must be committed to evaluation and refinement of the prototype.
• Customer must be capable of making requirements decisions in a timely manner.

Prototyping Methods and Tools

• Fourth generation techniques (4GT tools allow software engineer to generate executable code quickly)
• Reusable software components (assembling prototype from a set of existing software components)
• Formal specification and prototyping environments (can interactively create executable programs from software specification models)

Specification Principles

• Separate functionality from implementation.
• Develop a behavioral model that describes functional responses to all system stimuli.
• Define the environment in which the system operates and indicate how the collection of agents will interact with it.
• Create a cognitive model rather than an implementation model.
• Recognize that the specification must be extensible and tolerant of incompleteness.
• Establish the content and structure of a specification so that it can be changed easily.

Specification Representation

• Representation format and content should be relevant to the problem.
• Information contained within the specification should be nested.
• Diagrams and other notational forms should be restricted in number and consistent in use.
• Representations should be revisable.

Specification Review

• Conducted by customer and software developer.
• Once approved, the specification becomes a contract for software development.
• The specification is difficult to test in a meaningful way.
• Assessing the impact of specification changes is hard to do.