Ads
  

Facilitated Application Specification Techniques (FAST)

Facilitated Application Specification Techniques (FAST)

FAST is similar enough to brainstorming and to JAD that we will provide only cursory coverage here. This is not to belittle the process in any way - FAST is an important part of the software PM's vocabulary because it was developed to be a method particularly for gathering software requirements. But rather than attempt to rewrite existing texts, we will only summarize FAST and refer you to other works, such as Pressman's Software Engineering.

The general rules for FAST will seem familiar, as they are similar to those for brainstorming:

●  Conduct the meeting at a neutral site, attended by developers and customers.

●  Establish rules for preparation and participation.

●  Publish an informal agenda.

●  Invite a facilitator to control the meeting.

●  Prepare a definition mechanism - worksheets, flip charts, wall stickies, and so on.

●  Participants should agree not to critique or debate.

●  Share a goal:

1.  Identify the problem.

2.  Propose elements of the solution.

3.  Negotiate different approaches.

4.  Specify a preliminary set of solution requirements.

Preparation for a FAST session might include:

●  making a list of objects that are:

1.  part of the environment that surrounds the system;

2.  produced by the system;

3.  used by the system.

●  making a list of services (processes or functions) that manipulate or interact with the objects.

●  making a list of constraints and performance criteria.

Activities during a FAST session typically include:

●  presentation of prepared lists of objects, services, constraints, and performance for discussion (as separate entries so they can be moved, combined, etc.).

●  creation of a combined list, where redundant entries are eliminated, and new ideas are added.

●  consensus on the list, gained from the participants by the facilitator.

●  work, by teams, on "mini-specifications," or discrete portions of the known software requirements:

1.  discuss mini-specifications;

2.  identify externally observable data objects;

3.  evaluate the flow and content of information;

4.  define and elaborate software functionality;

5.  understand the software "behavior";

6.  establish interface characteristics;

7.  uncover design constraints.

●  maintenance of a "parking lot list of issues" to be resolved later.

●  creation of validation criteria.

●  assignments for the next step of drafting the SRS

Joint Application Design

As well as one-on-one interviews, interviews in small groups, brainstorming, and FAST sessions (with or without mind mapping), another type of extremely effective facilitated meeting is the Joint Application Design (JAD). As with the other requirements elicitation methods, it has been explained in various other works. Wood and Silver wrote the definitive book in 1989, which remains popular today. Here, we will present an overview of the JAD process; "Joint Application Design in Use" offers a glimpse into a recently completed real-life JAD exercise held between two major, just-merged, U.S. companies.

Definition of JAD

Joint Application Design (JAD) is a registered trademark of IBM Corporation. It is a team approach to requirements elicitation, focusing on improving the group process and getting the right people involved from the beginning of a project. Toby Crawford and Chuck Morris at IBM developed the initial concept of JAD in 1977. Through a marriage of the IBM methodology, business systems planning, and their own innovative methods, they got IT professionals and end-users to agree on requirement and design specifications. Since 1977, JAD has emerged as the most widely used tool for requirements definition. It isn't just for requirements, though - it is employed in the creation of other plans, designs, and policies throughout the software life cycle. Development organizations now realize that a methodology with a high degree of user interaction (including prototyping and RAD) leads to higher-quality software.

JAD sessions are similar to brainstorming sessions, but they aren't quite the same animal. Brainstorming sessions last about two hours; JAD sessions tend to last about three days. Brainstorming sessions are about rapid-fire production of ideas; JAD sessions can produce high-level, but specific, software models of function, data, and behavior.

JAD is a structured and disciplined session led by a facilitator. It is based upon communication through documentation, fixed requirements, and rules of work. As the JAD methodology evolved, it began to use CASE and other software tools during the sessions to capture work products such as data flow diagrams (DFDs), entity relationship diagrams (ERDs), state transition diagrams, and all commonly used object-oriented diagrams.

A 1989 study by Capers Jones of 60 development projects found that 35 percent of the functionality was missed without JAD, while less than 10 percent of the functionality was missed when JAD was incorporated into the requirements elicitation process. Projects combining JAD and prototyping did even better at managing requirements refinement.

Roles in JAD


Developers


The role of the developer is to assist stakeholders to formulate their needs, which are generally solutions to existing problems. The stakeholders share ownership of the software requirements.

Participants

Like the participant roles in brainstorming, these invited stakeholders are the most important part of this process. The knowledge and skill level of the invitees are crucial to the session's success. Having the right people allows decisions to be made rapidly and models to be developed that are correct, even if incomplete.

The Facilitator/Process Consultant

As with brainstorming, the facilitator keeps the session focused and flowing, and prevents or minimizes the acting out of unproductive human emotions such as attacks or defensiveness. The facilitator owns neither the process nor the product, but is present to help the stakeholders with their product creation process.

Scribe

As with brainstorming sessions, the JAD scribe(s) documents ideas and helps with timekeeping.

JAD Sessions

According to Wood, JAD provides a concentrated workshop for making decisions with everyone present who has the authority to make those decisions. She recommends phases of project definition and research to deal with fact-finding and information gathering, preparation for the JAD session, and the JAD session itself, to validate the gathered information. As with brainstorming, the JAD session will be supported with a properly outfitted room, including access to white boards, flip charts, markers, appropriately shaped and spaced worktables, projectors, wall charts, refreshment tables, and so on.

Ground rules/guidelines for JAD sessions mirror those for brainstorming sessions:

●  There are no "dumb" questions.

●  All participants are equal.

●  Silence means agreement, even (especially) if you're absent.

●  Any team member can request to go around the room and get explicit agreement from each person on a given issue.

●  No "speeches" are given.

●  No side conversations are allowed.

●  All team members are involved for the full period of time (three days are recommended).

●  One user scenario will be addressed at a time.

●  Brainstorming is for quantity, not quality.

●  Define terms and capture three-letter acronyms (TLAs).

●  All team members participate with an open mind.

●  All team members support each other, learn, grow, and relax and have a little fun.

Output from a JAD Session

It makes sense that the two groups, developers and stakeholders, will jointly own all deliverables from the JAD session where the joint authorship occurred. Frequently, these software-specific artifacts will include:

●  a data context diagram (see Figure 1);

Example of a Partial Data Context Diagram

●  a Level 0 data flow diagram;

●  a Level 1 data flow diagram;

●  a global data model - entity relationship diagram (see Figure 2);

Example of a Global Data Model

●  a list of primary objects;

●  a high-level object model (see Figure 3);

Example of a High-Level Object Model

●  candidate responsibilities and collaborators for each object;

●  a list of primary processes/use cases;

●  other data flow diagrams, state diagrams, decision trees, or decision tables where required;

●  data requirements for each process;

●  a list of assumptions;

●  documentation for the resolution or assignment of open issues.

Output from a JAD session used to elicit requirements paves the way for the next step - the creation of the SRS.

Possible Issues with JAD

No method is perfect, and while the JAD technique has been used successfully for several decades, there are a few recognized issues.

For instance, participants funnel their ideas through a facilitator and/or a scribe. Precautions must be taken to avoid misinterpretation of the collected data. The use of automated tools during the session and the review of the session deliverables by all participants reduces this risk.

JAD sessions have dealt primarily with IT systems, which emphasize data elements and screen design. The success of JAD used with real-time systems requirements elicitation has not been well documented.

A three-day JAD session with representatives of all stakeholder groups, all having decision-making authority, is an expensive proposition. Three days is only an average - a complex embedded real-time system, or a system upon which human life is dependent, could easily take longer. If the length of the session is "until we are done," a measure of "doneness" could be that no more use cases can be identified.

User Scenario and Use Case Development Sessions

As with so many other topics in this survey of practical methods, all things object-oriented constitute a huge body of knowledge. And, as we indicate with almost all of the subjects in this book, we are barely able to scratch the surface. We describe the basics of what a software project manager needs to know in terms of balanced, useful project, product, and people skills and give references for digging deeper into each area. Here, we have space to briefly mention use cases as a requirements elicitation technique. Object models will be addressed in "Analysis and Design Methods".

Requirements elicitation is a combination of textual and graphical models used to represent the intended system, detect inconsistencies, errors, omissions, and ambiguities. The text and pictures improve understanding of the requirements, bridging gaps in language and vocabulary. There are many software project managers who believe strongly that creating use case scenarios and diagrams during requirements gathering sessions (JAD, FAST) is a key to definition, user-system interaction, and a basis for validation.

Definition of a Use Case

The use case model is about describing what (not how) our system will do at a high level and with a user focus for the purpose of scoping the project and giving the application some structure. Use cases are scenarios that identify a particular thread of system usage - a written narrative. The terms use case, use case scenario, and use case diagram are often interchanged, but in fact they are different. Use cases are structured outlines or templates for the description of user requirements, modeled in a structured language (English). Use case scenarios are unstructured descriptions of user requirements. Neither is limited to object-oriented methods, but that is the arena in which they are generally discussed. Use case diagrams are graphical representations that may be decomposed into further levels of abstraction. In order to describe them, their components will be described first.

Actor

An actor, or external agent, lies outside of the system model, but interacts with it in some way. An actor can be a person, machine, or an information system that is external to the system model; an actor is not part of the system itself. Customers, client application, external systems (e.g., legacy systems, accounting systems), and external devices (e.g., fault monitors) could all be actors.

Use Case

A use case is narrative text describing the sequence of events of an actor, using a system. They are "stories" of how a system is used, illustrating and implying requirements. They are transactions (atomic sets of activities) that yield identifiable value to the actor. They represent a description of the courses of events that will be carried out by the system. A use case is a static model of functionality, having static relationships, implying no temporal sequencing.

Use Case Diagram

A use case diagram visually represents what happens when an actor interacts with a system. The system is shown as a rectangle with the name of the system (or subsystem) inside; the actors are shown as stick figures (even the nonhuman ones), the use cases are shown as solid-bordered ovals labeled with the name of the use case, and relationships are lines or arrows between actors and use cases and/or between the use cases themselves. Actors appear outside of the rectangle since they are external to the system. Use cases appear within the rectangle, providing functionality. A relationship or association is a solid line between an actor and each use case in which the actor participates - the involvement can be any kind, not necessarily one of the actor initiating the use case functionality. Figure 4 shows an example of a use case diagram.
Use Case Example

Richter tells us that the use case models system functions by describing how an actor uses the system. It represents a function that would make sense to an actor. Ask what interactions with the system the actor initiates, and what interactions with the actor the system initiates. A paragraph or more of text describes each use case, also known as a specification. First identify the system's actors and use cases, then combine the information into a use case diagram - a static model of functionality with static relationships, implying no temporal sequencing. It contains no information about the dynamics of these functions. Activity diagrams, which are described in Richter's book, Designing Flexible Object-Oriented Systems with UML, provide a solution to these deficiencies, depicting a workflow view of activities.

Benefits of Use Case

The use case model can be a key tool in understanding the requirements of the business, as well as a way of ensuring that everyone who uses the system or works with it can agree on how the model will look. The following list identifies some of the benefits:

●  Having consistent names for the different use cases facilitates communication and avoids errors caused by different people, or groups of people, thinking they are referring to the same thing when they really mean something different.

●  Use case diagrams can provide a documented model that accurately describes the existing business, as well as the system under development.

●  Use case models are understandable to managers, users, and developers, with no need for specialized training.

●  Use cases and scenarios can provide validation as well as implementation testing.

●  Use cases can be used to produce business rules.

●  Use cases define the process by which the customer interacts with the group.

●  Use cases may be easily transformed into object models.

●  Use cases provide traceability for functions.

●  Use cases provide the basic information needed for creating prototypes.

●  Use cases reduce the occurrence of the "orphan function" - one that sounds good but is not a direct contributor to the system goals.

●  Use cases show the courses of events that can be performed.

Guidelines for Creating Use Cases

As use cases are developed during requirements elicitation sessions, a few guidelines may be helpful:

●  Allow each use case to tell a story about how the user interacts with the system under development to satisfy a discrete goal (the conceptual dialog).

●  Assign project champions who are actual users for each user class to serve as the primary interface between users and developers.

●  Avoid design strategies at this point, including user interface design.

●  Avoid duplication across use cases.

●  Avoid creating too many use cases too quickly.

●  Don't record data definitions in use cases (data attributes belong in class diagrams, logical data models, and the project data dictionary).

●  Record the following about each use case:

  1.  a unique ID
  2.  a concise name
  3.  history - the originator, creation date, updater, last update date
  4.  the actor(s)
  5.  a brief description
  6.  pre- and post-conditions
  7.  priority
  8.  frequency of use
  9.  a detailed description of the user actions and system responses under normal, expected conditions
10.  alternative courses
11.  error conditions and system response
12.  includes (other use cases that may be called)
13.  special requirements
14.  assumptions
15.  comments

●  There should be more functional requirements than use cases.

During an elicitation session like FAST or JAD, the session leader may use the following steps to get the use case definition process started (see Figure 5):
1.  Identify who will use the system directly, for instance, hitting keys on the keyboard - these are the actors.

2.  Pick one of those actors.

3.  Define what that actor wants to do with the system; each of these major activities become a use case.

4.  For each use case determine the "basic course," what normally happens. Describe that basic course in the description for the use case.

5.  Describe it as "Actor does something, system does something; actor does something, system does something," but keep it at a high level. This is not the time to discuss user interface design. Describe only system functions that the actor would be aware of and what the actor does that the system would be aware of.

6.  Once you're happy with the basic course, consider the alternates (they will be added as extending use cases, described thoroughly in all of the referenced object-oriented literature).

7.  Review each use case description against the descriptions of the other use cases. Where commonality exists, document only one "used" use case to avoid duplication.

8.  Repeat Steps 2 through 7 for each actor.

Steps in Creating a Use Case

The last piece of advice we will leave for the use case modeler is to "keep it simple".


Tags

fast, brainstorming, jad, software requirements, elicitation methods
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus