Task I.1 Scope and bound the concept
I.1.1 Identify need, benefits, and potential customers.
Intent: The intent of this task is to identify the need for the application and to understand the benefits of its development and its potential customers.
Mechanics: This task can be accomplished through detailed discussions with the requester who has indicated the need for a concept development study. For process flow detail: Task I.1.1
Application of Formal Methods: none
Application of CASE Tools: none
SQA Checklist:
1. Have you met with all important requester personnel?
2. If the concept has been developed by multiple constituencies, have you met with them all?
3. Does management support the concept?
Do’s & Don’ts
Do: Be sure to understand the product request.
Do: For internal requests, express need in a way that can be directly translated to some business benefit. Ideally, the need should be expressed in bottom line terms.
Do: Consider how the technology being requested interrelates with other technologies and systems that already exist. These interrelationships should be specified.
Do: Encourage communication among all constituencies who have interest in the concept.
Don’t: Spend an inordinate amount of time worrying about feasibility. Until need and benefit is established, there is no point spending valuable time on feasibility.
Helpful Hints
1. The requester should be asked to state the need in a single sentence. This helps the requester to focus his/her thoughts and provides the developer with a point of departure for more detailed discussions.
2. The requester should be asked to develop a list of benefits and provide justification for each entry.
3. The requester should be asked to make a list of potential customers for the technology. In addition, the total number of installation sites should be estimated.
4. Once the requester has done the work implied by hints 1 - 3, meetings should be conducted to "flesh-out" the statement of needs and the lists.
Deliverables:
I.1.2 Define desired output/control and input events that drive the application.
Intent: The intent of these tasks is understand the potential application of the technology by understanding the data domain in which a technology concept exists. An unambiguous list of all major outputs and/or control actions produced by a software-based application of the technology is generated. After Task I.1.2 is complete, a list of all major inputs is also specified. At this stage, output is defined as a 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 software 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: These tasks can be accomplished in a number of different ways:
1. The requester can be asked to generate lists of output/control/ input independently.
2. The requester and developer can work together informally to create the required lists of output/control/input.
3. [For structured or strict projects] The requester and developer can work together using Quality Function Deployment (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 either quality function deployment, structured analysis or object-oriented analysis.
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Has the list of inputs and outputs been reviewed with the user for completeness?
2. Do you have a plan for items marked as to be defined?
3. Has the user specified the general format of all inputs and outputs?
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 "device output" means relatively little to most readers. It would be better to specify which device data are to be presented, e.g., "meter calibration settings."
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. Are 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?
Do: Represent relationships between data items, if the software has sophisticated data structures or makes use of a database.
Don’t: Rush to define functionality and/or behavior before you’ve defined the data domain for the software.
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 [Pressman, R.S., 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 requester requires as output from the system and what input 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 (entity-relationship) 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."
3. If QFD techniques are used, the following deliverables may be generated:
• customer ‘voice’ table - categorizes verbatim customer requests
• customer context table - organizes observation of product environment
• hierarchy diagram - prioritizes requirements
I.1.3 Define the functionality/behavior that each major function is to perform.
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.
Mechanics: These tasks can be accomplished in a number of different ways:
1. The requester can be asked to generate lists of function/behavior independently.
2. The requester and developer can work together informally to create the required lists of function/behavior.
3. [For structured or strict projects] The requester and developer can work together using QFD techniques to create the required lists function/behavior.
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 either quality function deployment, structured analysis or object-oriented analysis.
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Are all functions described at the same level of abstraction? Are they user visible?
2. Is the behavior of the system predictable and unambiguous?
3. Are data provided and I/O to major functions known?
4. Are events that drive the application behavior known?
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 - 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. A top-level data flow diagram can also be used.
2. A behavioral description that may take the form of a simple narrative (for simple system behaviors) or a top-level state transition diagram representation (for complex behaviors).
I.1.4 Isolate those elements of the technology to be implemented in software.
Intent: The intent of this task is to evaluate the technology functions and behavior described in Task I.1.3 and determine which of the functions will be implemented in software and how software will effect the behavior of the system.
Mechanics: A process of component allocation occurs during this step. Each function/behavior is allocated to one or more of the typical computer based system elements: people, hardware, software, and database.
Application of Formal Methods: see Information Engineering or System Engineering references
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Have the characteristics of other system elements (e.g., hardware, an external database) been considered?
2. Is the functionality allocated to software achievable within the range of resources that are likely for the project?
3. Has an overall system model been created and reviewed?
4. Are other system components defined in a bounded manner?
5. Have interoperability concerns with other system or products been considered? Have they been documented and reviewed?
Helpful Hints
1. Make use of schematic diagrams or some more formal notation (e.g., Hatley/Pirbhai architecture diagrams) to represent the software element and how it interacts with other technology components.
2. Although it is too early to consider interface characteristics in detail, you should be certain that basic information/control flow between technology components is understood.
Deliverables
1. Description of the software component and its interfaces to other technology components
2. Schematic diagram of all technology components
I.1.5 Research availability of existing software.
Intent: The intent of this task is to determine whether the software components described in Task I.1.4 already exist within the company or as products/components that can be purchased from outside sources.
Mechanics: Using tasks I.1.2 through 1.1.4, develop an outline of requirements for the software. Use internal information sources and external directories to conduct a search. Research any candidate software that is found. See umbrella activity Task U.6, Reusability Management, for further information.
Application of Formal Methods: none
Application of CASE Tools: t,b.d.
SQA Checklist:
1. Has the team made a active effort to find reusable software components?
2. Is there adequate documentation for all reusable components?
3. Are regression test suites available for reusable components?
4. If reusable software is to be acquired from an outside vendor, has a specification been written for such software? Has it been reviewed for ambiguity and completeness?
Do’s and Don’ts
Do: Assess the source of the software. Does the source have a reputation for developing high quality software?
Don’t: Assume that an existing piece of software developed for another product can be translated to a new product without modification.
Don’t: Acquire software that has not been proven in similar application areas.
Don’t: Acquire software from universities, unless there is no other option. Such software is notoriously difficult to modify.
Don’t: Assume that "a few simple modifications" will be either simple or few.
Helpful Hints
1. Use information developed in earlier tasks to develop a mini-spec for your search.
2. Be certain to "check references" for any candidate software package.
3. Be certain to assess the difficulty of integrating "alien" software with software that you’ll be developing in-house.
4. Avoid mixed-language systems - they are generally more difficult to maintain.
Deliverables
1. List of potentially useful software components
2. List of modifications that will be required to integrate the existing software into the new product or application
3. List of technology risks associated with acquiring existing software
I.1.6 Define technical feasibility.
Intent: The intent of this task is to describe the feasibility of implementing the technology functions and behavior described in Task I.1.3 and the components described in I.1.4. Does the technology exist in a form that can be translated into a computer-based application or product?
Mechanics: The technology is researched to understand the degree to which it can be translated into a computer-based application or product. Technical papers, related technologies and area experts are all used as sources of information.
Application of Formal Methods: none
Application of CASE Tools: t.b.d
Do’s & Don’ts
{Application area dependent. To be defined by the project team.}
Helpful Hints
{Application area dependent. To be defined by the project team.}
Deliverables: Concept Feasibility Report
I.1.7 Make quick estimate of 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 requester and/or potential 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: t.b.d.
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
Use the results of task I.1.3 and I.1.4 to do a functional decomposition for the project. The effort required to implement each function can then be estimated. Alternatively, the size of each function can be estimated and historical data can be used to translate size into estimated effort. See umbrella activity, Task U.1, Software Project Management, for additional details.
Deliverables: Rough estimates of effort and duration
I.1.8 Create a Scope Definition.
Intent: The intent of this task is to write a Scope Definition that summarizes work conducted in Tasks I.1.1 through I.1.7.
Mechanics: Deliverables produced as part of tasks I.1.1 through I.1.7 are organized into a Scope Definition.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Is the entire scope written at the same level of abstraction? Are all descriptions characterized in the customer/user’s frame of reference?
2. Has the statement of scope been reviewed with the customer?
3. Does the statement of scope define input, processing and output? Does it describe behavior and events?
4. Is the statement of scope bounded?
Do’s & Don’ts:
Do: Strive for clarity and brevity in the Scope definition.
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:
Very little additional writing need occur during this task. If you’ve performed tasks I.1.1 through I.1.7 properly, all of the information that you’ll need is contained in the deliverables produced as part of those tasks.
Deliverables: Scope Definition [For most projects, the Scope Definition may be a one to three page outline of key information elicited during Tasks I.1.1 - I.1.7.]
Use Browser "back" arrow or return to APM Process Design Language Description
