II.7.1 Conduct meeting with customer to acquire application domain specific or product domain specific information.
Intent: The intent of these tasks is to isolate application domain specific or product domain specific requirements for the software work to be conducted. It should be noted that the work associated with this task incorporates some or all of the activities defined for Tasks II.7.2 - II.7. 7.
Mechanics: This task can be accomplished with an informal customer-developer meeting, or for projects that require a more disciplined approach, quality function deployment (QFD) techniques may be appropriate. Regardless of its formality, the meetings with the customer must have an agenda, a leader, a recorder, and the right people in attendance. All attendees should prepare in advance. In addition, meetings may have to be augmented by other QFD observations and data collection.
Application of Formal Methods: QFD techniques, when required
Application of CASE Tools: none
SQA Checklist:
1. Has the information developed during the customer meeting been reviewed for completeness and consistency after the meeting?
2. Is all data domain information represented at a consistent level of abstraction?
3. Were the right people at the customer-developer meeting?
Do's & Don'ts
Do: Establish meeting guidelines in advance.
Do. Appoint a meeting leader or facilitator and establish an agenda.
Do: Treat this meeting as much as a "team building" activity as a technical or information gathering activity. The idea is to establish a "team" that includes both software developer and customer.
Don't: Allow this meeting to take on an adversarial tone.
Don't: Come to the meeting unprepared. An agenda should be distributed in advance and everyone in attendance should understand his/her role.
Helpful Hints
1. For further information on QFD techniques see Bossert, J.L., Quality Function Deployment: A Practitioner's Approach, ASQC Quality Press, 1991.
Deliverables:
• list of data items to be produced
• list of control items to be produced
• list of data and control inputs
• list of product functions
• list of design constraints and performance requirements
II.7.2 Define data domain of the application.
Intent: The intent of this task is to understand the data domain of the application. An unambiguous list of all major outputs and/or control actions produced by the software. A list of all major inputs is also specified. At this stage, output is defined as an composite collection of data that will provide useful information to a potential customer. A control action is any monitoring or control activity that causes the application to interact with the outside world. Input is defined as any data or event recognized by the software and used directly or indirectly to produce output.
Mechanics: This task can be accomplished in a number of different ways:
1. The customer can be asked to generate lists of output/control/ input independently.
2. The customer and developer can work together informally to create the required lists of output/control/input.
3. [For structured or strict projects] The customer and developer can work together using QFD techniques to create the required lists of output/control/input.
The approach to be taken will be dictated by the adaptation criteria established for your project.
Application of Formal Methods: Projects that fall into the structured or strict project categories may opt to use one or more of the following methods:
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has a data model been created?
2. Have data objects, relationships and attributes been specified as part of this task?
3. Are all data objects visible by the end-user of the application?
Do's & Don'ts
Do: Define each output/input with with a meaningful name and specify its content in terms of the major data items that the output/input contains. An output with the name "control bit" means relatively little to most readers. It would be better to specify the meaning of the control item, e.g., "jam indicator signal."
Do: Consider only outputs/inputs that are visible to the end-user. Avoid specifying intermediate outputs (e.g., a temporary data file) or inputs (e.g., a system clock) that have no direct connection with the end user.
Do: Prioritize your lists. Is some output/input desirable but not absolutely essential.
Do: Suggest the general form that the output/input information should take. Is the data to be tabular, graphical, or report oriented?
Don't: Rush to define functionality and/or behavior before you've defined the data domain for the application.
Don't: Get bogged down in unnecessary detail. It is not necessary to define every data item that composes an output/input at this stage. In fact it can be counter-productive because it limits flexibility later.
Helpful Hints
1. If you're struggling with getting started on these tasks, use the "grammatical parse" method described in Pressman (Software Engineering: A Practitioner's Approach, 5/e, McGraw-Hill, 2001). It should provide you with a good indication of both inputs and outputs (as well as necessary information for completing Task I.1.4).
2. The key to getting this task completed is to avoid getting caught up in a "How are we going to generate this output?" discussion. At this stage, you're trying to identify what the customer requires as output from the system and what inputs will be provided to generate the output. How input will be transformed into output is not of concern at this time.
3. As you begin to create your list, write down all suggestions for outputs/inputs, no matter how unusual. Later, you'll revisit your initial list and eliminate entries that are not relevant or practical.
4. For those readers that have been trained in structured analysis, the lists to be generated are at a "context level." Ask yourself the following question: "What output/input flows across the boundary of the system."
5. If the discussion of output/input implies a need for a formal data base system, you may decide to develop a preliminary model of the relationships between major output and input items. E-R notation can be used to accomplish this.
Deliverables:
1. List of outputs and inputs with as much descriptive information as necessary to eliminate ambiguity. Remember that output/input names should be meaningful and should conform to the terminology of the application area.
2. Priorities that define which output/input are required and which "would be nice to have."
II.7.3 Define the functions/behaviors that the software is to perform and the computing environment in which the software will reside.
Intent: The intent of this task is first to create an unambiguous list of all major functions that the software is required to perform. After that is accomplished, a description of the overall behavior of the software is also produced. A function is defined as a data or control transformation. Behavior is defined as the way in which the software reacts to externally observable events. Finally, this task describes the computing environment (hardware and software) in which the application will reside.
Mechanics: See Mechanics for Task II.7.2
Application of Formal Methods: Projects that fall into the structured or strict project categories may opt to use one or more of the following methods:
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has a functional hierarchy been defined for the application?
2. Has each major function been described with an English language paragraph?
3. Are all functions understood?
4. Are the interfaces to/from all functions understood?
Do's & Don'ts
Do: Define each function/behavior with with a meaningful name and specify it with a one or two line processing narrative.
Do: Consider only major functions and behaviors.
Don't: Get bogged down in unnecessary detail. It is not necessary to design the system at this stage. Be concerned with what must be accomplished&endash;not how it will be done.
Helpful Hints
1. The list of output/input will provide important information for the creation of both functions and behaviors. When input and output are listed, the functions required to transform input into output become relatively obvious (at least at a high level).
2. The key to getting this task completed is to avoid worrying about "how to" detail at this point. The details of implementing the functions are postponed until the design task and should not be considered here.
3. For those readers that have been trained in structured analysis, the lists to be generated will provide a first hint of the first level data flow diagrams.
4. If complex behavior is envisioned, the use of state transition diagrams can be initiated at this time.
Deliverables:
1. List of functions with corresponding processing narrative for each function. The processing narrative is a natural language description of what the function is to accomplish, the data input to it and the output that it produces.
2. A behavioral description that make take the form of a simple narrative (for simple system behaviors) or a top-level state transition diagram representation (for complex behaviors).
II.7.4 Define technical constraints.
Intent: The intent of this task is to list all known technical constraints for the software. Technical constraints are defined as any externally imposed condition that will affect the manner in which the software design is to be developed or the resulting source code is to be implemented or tested. Examples include memory limitations, special interfaces and/or interoperability conditions, special timing requirements, communications protocols, etc.
Mechanics: Technical constraints are determined by conducting a thorough study of the known interfaces to the software, the environment in which the application is to reside (see Task II.7.4), and the performance and behavioral requirements imposed by the customer.
Application of Formal Methods: none
Application of CASE Tools: none
SQA Checklist:
1. Have constraints due to interoperability been identified?
2. Have user constraints been defined?
3. Have constraints imposed by business processes been identified?
4. Have constraints imposed by hardware been described?
5. Have constraints imposed by existing files or databases been identified?
6. Have performance constraints associated with algorithms been defined?
7. Have software design constraints, imposed by reusable components been identified?
Do's & Don'ts
Do: Focus only on those externally imposed conditions that will change the way in which design, code or test must be conducted. In some cases, these conditions will be environmental (e.g., a specific operating system or platform, the need for a specific test rig). In other cases, conditions may be imposed by the customer (e.g., the need for a specific mode of input (e.g., voice) or output (purely graphical).
Do: Make a preliminary estimate of the risk imposed by the technical constraint.
Do: Note any special resources that will be required to accommodate the constraint.
Don't: Assume that dealing with constraints is someone else's problem or the condition lies outside the jurisdiction of software development.
Don't: Move on until you've acquired additional technical information about the constraint condition (or established the acquisition of such information as an action item).
Helpful Hints
1. Your group should develop a generic application domain "technical constraint checklist." This one time activity will save you time as you execute this task for all future projects. Add to it as time passes. To get you started, here are some suggestions:
System/Product level constraints:
• operating system
• remote communications
• special requirements for security
• client-server environment issues
• special networking requirements
• special timing issues
Application level constraints:
• special human interface (e.g., voice)
• multiple natural language support (e.g., English and Spanish)
• special data storage or data representation requirements
• unusual user profile
Add to these lists as appropriate.
2. Attach a subjective assessment (e.g., a 0 to 10 scale) of the impact of the constraint on the ease with which the application will be built.
3. At this stage, do not worry about "workarounds" for the constraint. Assume that you'll have to live with it and assess risk accordingly.
Deliverables:
1. List of technical constraints by constraint category
2. Description of each technical constraint, as required.
II.7.5 Define validation criteria.
Intent: The intent of this task is to describe the manner in which the implemented system will be tested to demonstrate conformance to its requirements. This task defines the broad classes of tests to be conducted. It does not specify test data or define the strategy or mechanics of testing.
Mechanics: This task can be accomplished in a number of different ways:
1. The customer can be asked to generate a "qualification scenario" for the software. The qualification scenario defines the types of tests that must be conducted to fully demonstrate conformance to requirements.
2. The customer and developer can work together informally to create a qualification scenario.
3. The customer and developer can work together using QFD techniques to create a qualification scenario.
The approach to be taken will be dictated by the adaptation criteria established for your project.
Application of Formal Methods: Projects that fall into the structured or strict project categories may opt to use QFD techniques.
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Does the deliverable define how to recognize a successful implementation of the application?
2. Are the classes of tests fully defined?
3. Is an overall strategy for testing identified?
4. Are other SQA activities defined?
Do's & Don'ts
Do: Answer the following question: How would I recognize a successful implementation of this application if it were dropped on our desk tomorrow?
Do: Focus attention on input and conforming output.
Do: Note any special resources that will be required to perform validation.
Don't: Worry about "demonstrating that the system works." Instead, demonstrate that required output is produced - a subtle yet important difference in viewpoint.
Don't: Skip this task! It is the primary input for test planning and serves as a review of your understanding of scope.
Helpful Hints
1. Focus on the data/control domain of the software and suggest classes of tests that will demonstrate that specific classes of output are being produced according to requirements.
2. Cross check your classes of tests to be certain that all functions listed in Task II.7.3 will be exercised. If a function has not be exercised, suggest a class of tests to validate it.
3. Cross check your classes of tests to be certain that all behaviors listed in Task II.7.3 will be exercised. If a behavior has not be exercised, suggest a class of tests to validate it.
Deliverables: List of test classes with an explanation of their purpose.
II.7.6 Make a quick estimate of project size.
Intent: The intent of this task is to develop a "ball park" estimate of project effort and duration and to determine whether these efforts conform to the budget and expectation of the customers.
Mechanics: This task can be accomplished by using the effort and duration expended on similar past projects as a guideline.
The risk associated with implementing a new technology should weigh heavily in any estimate.
Application of Formal Methods: none
Application of CASE Tools: none
Do's & Don'ts
Do: Use information discerned from earlier tasks to help make your estimate.
Don't: Expect a high accuracy at this stage. Your intent is to do a "sanity check" on the viability of approaching this technology.
Helpful Hints
1. Use the results of Task II.7.3 to do a functional decomposition for the project. The effort required to implement each function (or alternatively, the function's size in LOC or function points) can then be estimated.
Deliverables: Rough estimates of effort and duration
II.7.7 Create a statement of Software Scope.
Intent: The intent of this task is to write a document that will serve as a basis for project planning (Task II.8), risk assessment (Task II.9) and prototyping or analysis activities (Task II.10).
Mechanics: Deliverables produced as part of Tasks II.7.1 through II.7.6 are organized into a Software Scope document.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Does the statement of scope define the application in an unambiguous fashion?
2. Is the statement of scope complete at this level of abstraction?
3. Can the statement of scope be easily understood by the customer and end-user?
4. Is the statement of scope bounded?
5. Is all terminology contained in the statement of scope understood by all readers?
Do's & Don'ts
Do: Strive for clarity and brevity in the Software Scope document, but be sure to bound information to the extent possible.
Don't: Try to write a Requirements Spec at this time. You intent is merely to bound the remainder of the concept feasibility project.
Helpful Hints
1. Very little additional writing need occur during this task. If you've performed tasks II.7.1 through II.7.6 properly, all of the information that you'll need is contained in the deliverables produced as part of those tasks.
Deliverables: Software Scope document
Note: For projects in the casual or structured project categories the Software Scope may be a one to three page outline of key information elicited during earlier tasks.
Use Browser "back" arrow or return to APM Process Design Language Description
