Analysis Modelling in Software Engineering

The analysis model must achieve three primary objectives:

• o describe what the customer requires,
• To establish a basis for the creation of a software design, and
• To define a set of requirements that can be validated once the software is built.

To accomplish these objectives, the analysis model derived during structured analysis takes the form illustrated in Figure given below.

At the core of the model lies the data dictionary—a repository that contains descriptions of all data objects consumed or produced by the software. Three different diagrams surround the core.

• The entity relation diagram (ERD) depicts relationships between data objects. The ERD is the notation that is used to conduct the data modeling activity. The attributes of each data object noted in the ERD can be described using a data object description.
• The data flow diagram (DFD) serves two purposes:
  • to provide an indication of how data are transformed as they move through the system and
  •  To depict the functions (and subfunctions) that transforms the data flow.

The DFD provides additional information that is used during the analysis of the information domain and serves as a basis for the modeling of function. A description of each function presented in the DFD is contained in a process specification(PSPEC).

Process specification The process specification (PSPEC) is used to describe all flow model processes that appear at the final level of refinement. The content of the process specification can include narrative text, a program design language (PDL) description of the process algorithm, mathematical equations, tables, diagrams, or charts.

By providing a PSPEC to accompany each bubble in the flow model, the software engineer creates a “minispec” that can serve as a first step in the creation of the Software Requirements Specification and as a guide for design of the software component that will implement the process.

              DFD graphical notation must be augmented with descriptive text. A process specification (PSPEC) can be used to specify the processing details implied by a bubble within a DFD. The process specification describes the input to a function, the algorithm that is applied to transform the input, and the output that is produced.

In addition, the PSPEC indicates restrictions and limitations imposed on the process (function), performance characteristics that are relevant to the process, and design constraints that may influence the way in which the process will be implemented.

• The state transition diagram(STD) indicates how the system behaves as a consequence of external events. To accomplish this, the STD represents the various modes of behavior (called states) of the system and the manner in which transitions are made from state to state. The STD serves as the basis for behavioral modeling. Additional information about the control aspects of the software is contained in the control specification (CSPEC).

Control Specification

The control specification (CSPEC) represents the behavior of the system in two different ways.

• The CSPEC contains a state transition diagram that is a sequential specification of behavior.
• It can also contain a program activation table—a combinatorial specification of behavior.

The CSPEC describes the behavior of the system, but it gives us no information about the inner working of the processes that are activated as a result of this behavior.

Requirement Gathering Techniques

Requirements gathering techniques provide project team members with a choice of methods for eliciting needs or requirements from stakeholders and for validating requirements with stakeholders.  Certain techniques are appropriate in gathering stakeholder needs, while other techniques are most helpful in defining high-level and detailed requirements, or validating detailed requirements with the stakeholders.

List and description of requirement analysis techniques/methods;

Interviewing

An interview is a conversation with stakeholders to elicit or validate needs and requirements.  An interview may include one or more stakeholders.  The interview may also involve a question and answer session used to discover other potential stakeholders and any discrepancies between needs; the high-level requirements derived from those needs; and the resulting detailed requirements.  Interviews facilitate obtaining approval from stakeholders on their needs, requirements, and any changes to them.

Types of Interview Questions

• Open-Ended
  • No pre-specified answers
• Close-Ended
  • Respondent is asked to choose from a set of specified responses

• Simple direct technique
• Context-free questions can help achieve bias-free interviews – See course web site for examples
• Then, it may be appropriate to search for undiscovered requirements by exploring solutions.
• Convergence on some common needs will initiate a “requirements repository” for use during the project.

Advantages

• Generally easy, because it can be done with minimal preparation.
• Interviews of individuals and small groups require less planning and scheduling effort than large workshops.
• Interviews of individuals and small groups require less stakeholder commitment than large workshops.
• Interviews provide an opportunity to explore or clarify topics in more detail.

Disadvantages

• The questions used in the interview may reflect the interviewer’s preconceived ideas, which can influence the responses.
• For projects with a large number of stakeholders the interviews technique can be time-consuming and inefficient.
• Conflicts and inconsistencies between stakeholder information need to be resolved in additional interviews.
• This technique does not allow different stakeholders to hear and elaborate upon the information being relayed.

Questionnaires

Overall Questioning Strategies.

• General area, narrowing to specific topic (preferred)
  • Tell me about CTI site, then Courses, then Course Information, then enrollment numbers
• Specific topic, moving to General
  • Enrollment numbers on Course Info page to CTI site in general

•  A questionnaire is no substitute for an interview. 
• Goal is to prevent prejudicing the user’s response to the questions.
  • Examples:
  • Who is the user?
  • Who is the customer?
  • Are their needs different?
  • Where else can a solution to this problem be found?
• Establish Customer or User Profile
• Assessing the Problem
• Understanding the User Environment
• Recap the Understanding
• Analyst’s Inputs on Customer’s Problems
• Context-free questions also parallel the questions salespeople are taught to ask as part of a technique called “solutions selling.”
• After context-free questions are asked, suggested solutions can be explored

On site observation

The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked.

Document Analysis / study existing system / Record Review

Reviewing the documentation of an existing system can help when creating  process documents, as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the requirements that drove creation of the existing system – a starting point for documenting current requirements. By studying the existing system most of requirements can be gathered about proposed software system.

Joint Application Development (JAD) Technique

Brings together key users, managers and systems analysts

• Purpose: collect system requirements simultaneously from key people
• Conducted off-site

The Joint Application Development (JAD) technique is an extended, facilitated workshop.  It involves collaboration between stakeholders and systems analysts to identify needs or requirements in a concentrated and focused effort.

       Joint Application Development (JAD) is a development methodology system originally used for designing a Computer-based software, but can be applied to any development process. It involves continuous interaction with the users and different designers of the system in development. JAD centers around a workshop session that is structured and focused. Participants of these sessions would typically include a facilitator, end users, developers, observers, mediators and experts.  JAD allows for a faster development process and minimizes errors at the same time. JAD also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on. JAD is called JRD (Joint Requirements Development)

Advantages

• This technique allows for the simultaneous gathering and consolidating of large amounts of information. 
• This technique produces relatively large amounts of high-quality information in a short period of time.
• Discrepancies are resolved immediately with the aid of the facilitator.
• This technique provides a forum to explore multiple points of view regarding a topic.

Disadvantages

• Requires significant planning and scheduling effort.
• Requires significant stakeholder commitment of time and effort.
• Requires trained and experienced personnel for facilitation and recording.

JAD Process Steps

• Define Session: Define the purpose, scope, and objectives of the JAD session, selecting the JAD team, invite and obtain commitment to attend sessions from the appropriate stakeholders, and schedule the session. It is important to obtain management commitment to support the process and identify the appropriate stakeholders. 
• Research Product: Become more familiar with the product or service; gather preliminary information, obtaining any models.
• Prepare: Prepare any visual aids, developing a realistic agenda, training the recorder, and preparing the meeting room.
• Conduct Session: Follow agenda to gather and document the project needs and requirements.  It is important to ensure all participants are given equal treatment during the process.
• Draft the Documents: Prepare the formal documents.  The information captured in the JAD session is further refined through analysis efforts, open questions or issues discovered through the sessions are resolved, and the final document is returned to stakeholders for review and validation.

FAST (Facilitated Application Specification Techniques)

Misunderstandings abound, important information is omitted, and a successful working relationship is never established. It is with these problems in mind that a number of independent investigators have developed a team-oriented approach to requirements gathering that is applied during early stages of analysis and specification which is called facilitated application specification techniques (FAST).

FAST encourages the creation of a joint team of customers and developers who work together to identify the problem, propose elements of the solution, negotiate different approaches and specify a preliminary set of solution requirements.

FAST has been used mostly by the information systems community, but the technique offers potential for improved communication in applications of all kinds.

Many different approaches to FAST have been proposed.

Following are the basic guidelines:

• A meeting is conducted at a neutral site and attended by both software engineers and customers.
• Rules for preparation and participation are established.
• An agenda is suggested that is formal enough to cover all important points but informal enough to encourage the free flow of ideas.
• A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat room or virtual forum) is used.
• The goal is to identify the problem, propose elements of the solution, negotiate different approaches, and specify a preliminary set of solution requirements in an atmosphere that is conducive to the accomplishment of the goal.

A meeting place, time, and date for FAST are selected and a facilitator is chosen. Attendees from both the development and customer/user organizations are invited to attend. The product request is distributed to all attendees before the meeting date.

Two of the more popular approaches to FAST are joint application development (JAD), developed by IBM and the METHOD, and developed by Performance Resources.

While reviewing the request before the meeting, each FAST attendee is asked to

• Make a list of objects that are part of the environment that surrounds the system, other objects that are to be produced by the system, and objects that are used by the system to perform its functions.
• Make another list of services (processes or functions) that manipulate or interact with the objects.
• Finally, lists of constraints (e.g., cost, size, business rules) and performance criteria (e.g., speed, accuracy) are also developed.
• The attendees are informed that the lists are not expected to be exhaustive but are expected to reflect each person’s perception of the system.

After individual lists are presented in one topic area, a combined list is created by the group. The combined list eliminates redundant entries, adds any new ideas that come up during the discussion, but does not delete anything. After combined lists for all topic areas have been created, discussion—coordinated by the facilitator—ensues.

The combined list is shortened, lengthened, or reworded to properly reflect the product/ system to be developed.

The objective is to develop a consensus list in each topic area (objects, services, constraints, and performance).

Once the consensus lists have been completed, the team is divided into smaller subteam; each works to develop mini- specifications for one or more entries on each of the lists. Each mini-specification is an elaboration of the word or phrase contained on a list.

• Each sub team then presents each of its mini-specs to all FAST attendees for discussion.
• Additions, deletions, and further elaboration are made. The development of mini-specs will uncover new objects, services, constraints, or performance requirements that will be added to the original lists.
• During all discussions, the team may raise an issue that cannot be resolved during the meeting. An issues list is maintained so that these ideas will be acted on later.
• After the mini-specs are completed, each FAST attendee makes a list of validation criteria for the product/system and presents his or her list to the team.
• A consensus list of validation criteria is then created.
• Finally, one or more participants are assigned the task of writing the complete draft specification using all inputs from the FAST meeting.

Requirements workshops – Braining Storming and idea reduction

• Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important.
• The requirements workshop is perhaps the most powerful technique for eliciting requirements.
• It gathers all key stakeholders together for a short but intensely focused period.
• The use of an outside facilitator experienced in requirements management can ensure the success of the workshop.
• Brainstorming is the most important part of the workshop.

Prototyping

• Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people cannot articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.
• Prototyping is especially effective in addressing the “Yes, But” and the “Undiscovered Ruins” syndromes.
• A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements.
• Prototype the “fuzzy” requirements: those that, although known or implied, are poorly defined and poorly understood.
• Repetitive process
• Rudimentary version of system is built
• Replaces or augments SDLC
• Goal: to develop concrete specifications for ultimate system
• Quickly converts requirements to working version of system
• Once the user sees requirements converted to system, will ask for modifications or will generate additional requests
• Is prototyping useful in any of these cases? 
  • User requests are not clear
  • Few users are involved in the system
  • Designs are complex and require concrete form
  • History of communication problems between analysts and users
  • Tools are readily available to build prototype

Use Cases

• Use cases comprise ‘stories’ which describe how certain processes work eg who can do what within the process. They describe the system from the user point of view. The systems requirements are gathered by working through a number of processes / use cases.
  
  Advantages: It can be easier for some users to describe what they do and the processes they go through, than specifying requirements.
  
  Disadvantages: Processes and stories still need to be analysed and documented into requirements. Time is taken to go through processes. If the focus is on existing processes, the information may not be so relevant, as processes often change with a new system implementation.

• Use Cases identify the who, what, and how of system behavior.
• Use Cases describe the interactions between a user and a system, focusing on what they system “does” for the user.
• The Use Case model describes the totality of the systems functional behavior.
• Early stages:  After you have an overview of the use cases, perhaps only by a phrase apiece, expand 10% of them in detail.

Data Flow Diagrams – Introduction

Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.

            A DFD shows what kinds of data will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel

A data flow diagram represents the following:

• External devices sending and receiving data
• Processes that change that data
• Data flows themselves
• Data storage locations
• A DFD illustrates those functions that must be performed in a program as well as the data that the function will need.

Data Flow Diagrams – Definition

A data flow diagram is a graphical representation that depicts information flow and the transforms that are applied as data move from input to output. The basic form of a data flow diagram, also known as a data flow graph or a bubble chart. A DFD shows the flow of data through a system. It views a system as a function that transforms the inputs in to desired output. The data flow diagram may be used to represent a system or software at any level of abstraction.

Or

A network representation of a system, the system may be automated, manual, or mixed.  The DFD portrays the system in terms of its component pieces, with all interfaces among the components indicated.”  Hence DFDs: Focus on the movement of data between external entities and processes, and between processes and data stores.

Or

A data flow diagram (DFD) is a graphical representation of the “flow” of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated. DFDs can also be used for the visualization of data processing (structured design).

Purposes / Advantages of Date Flow Diagram

• It tracks any information entering or leaving the system.
• It depicts how changes to information take place.
• It represents how and in what form the information is getting stored.
• DFDs are easier to understand by technical and non-technical audiences
• DFDs can provide a high level system overview, complete with boundaries and connections to other systems
• DFDs can provide a detailed representation of system components.

Data Flow Diagrams – Diagram Notation/DFD Elements           

There are some symbols which are used in the drawing of business process diagrams (data flow diagrams). These are as follows;

External Entity /Source/ Sink                

An external entity is a source or destination of a data flow which is outside the area of study. Only those entities which originate or receive data are represented on a business process diagram. An External Entity can be a person, organization, or system that is external to the system but interacts with it.

 The symbol used is an Oval/Rectangle containing a meaningful and unique identifier.

Process      

A Process is an activity or function performed for a specific business reason.

A Process may be manual or computerized.

A process shows a transformation or manipulation of data flows within the system. The symbol used is a Circle.

Data Flow

A data flow shows the flow of information from its source to its destination. A data flow is represented by a line, with arrowheads showing the direction of flow. Information always flows to or from a process and may be written, verbal or electronic. Each data flow may be referenced by the processes or data stores at its head and tail, or by a description of its contents.

Data Store

A data store is a holding place for information within the system: It is represented by an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be short-term accumulations: for example batches of documents that are waiting to be processed. Each data store should be given a reference followed by an arbitrary number

Levels of DFD

Context Level / Zero Level DFD

A context diagram is a top level (also known as Level 0) data flow diagram. It only contains one process node (process 0) that generalizes the function of the entire system in relationship to external entities.

                                         A context diagram is a graphic design that clarifies the interfaces and boundaries of the project or process at hand. It not only shows the process or project in its context, it also shows the project’s interactions with other systems and users.

A context diagram is “is the highest level view of a system . . . showing a . . . system as a whole and its inputs and outputs from/to external factors.” Further, a context diagram “shows the interactions between a system and other actors with which the system is designed to interface.

System context diagrams can be helpful in understanding the context which the system will be part of.            

Data sources, external communications, alternative scenarios, or anything not part of the main function or system you are diagramming does not need to be included in Context Level Diagram.

Points to Remember for Zero Level DFD

• Top-level view of IS (information System)
• A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system
• Example: Order system that a company uses to enter orders and apply payments against a customer’s balance

Level- 1 DFD

The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until you reach pseudo code.

Creating a Data Flow Model

The data flow diagram enables the software engineer to develop models of the information domain and functional domain at the same time. As the DFD is refined into greater levels of detail, the analyst performs an implicit functional decomposition of the system, thereby accomplishing the fourth operational analysis principle for function.

At the same time, the DFD refinement results in a corresponding refinement of data as it moves through the processes that embody the application.

A few simple guidelines can aid immeasurably during derivation of a data flow diagram:

• The level 0 data flow diagram should depict the software/system as a single bubble;
• Primary input and output should be carefully noted;
• Refinement should begin by isolating candidate processes, data objects, and stores to be represented at the next level;
• All arrows and bubbles should be labeled with meaningful names;
• Information flow continuity must be maintained from level to level, and
• One bubble at a time should be refined. There is a natural tendency to overcomplicate the data flow diagram.
• Do not attempt to show too much detail too early or represents procedural aspects of the software in lieu of information flow.
• Never try to show control logic.
• Label each arrow with proper data elements. Inputs and outputs of each transform should be carefully identified.
• Try drawing alternate data flow graphs before setting on one.

Common errors in DFD

• Unlabeled data flows
• Missing Data Flows; information required by a process is not available
• Extraneous data flows; some information is not being used in the process
• Consistency not maintained during refinement
• Missing processes
• Contains some control information

Data Dictionary

The data dictionary is an organized listing of all data elements that are pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and intermediate calculations.

Today, the data dictionary is always implemented as part of a CASE “structured analysis and design tool.” Although the format of dictionaries varies from tool to tool, most contain the following information:

• Name—the primary name of the data or control item, the data store or an external entity.
• Alias—other names used for the first entry.
• Where-used/how-used—a listing of the processes that use the data or control item and how it is used (e.g., input to the process, output from the process, as a store, as an external entity.
• Content description—a notation for representing content.
• Supplementary information—other information about data types, preset values (if known), restrictions or limitations, and so forth.
• “Where-used/how-used” information is recorded automatically from the flow models. When a dictionary entry is created, the CASE tool scans DFDs and CFDs to determine which processes use the data or control information and how it is used.

The notation used to develop a content description is noted in the following table:

Data Construct Notation Meaning

• = is composed of
• Sequence + and
• Selection [ | ] either-or
• Repetition { }n nrepetitions of
• ( ) optional data
• * … * delimits comments

The notation enables a software engineer to represent composite data in one of the three fundamental ways that it can be constructed:

• As a sequence of data items.
• As a selection from among a set of data items.
• As a repeated grouping of data items. Each data item entry that is represented as part of a sequence, selection, or repetition may itself be another composite data item that needs further refinement within the dictionary.

Example:  The data item telephone number is specified as input. But what exactly is a telephone number? It could be a 7-digit local number, a 4-digit extension, or a 25-digit long distance carrier sequence.

• The data dictionary provides us with a precise definition of telephone number for the DFD in question.
• In addition it indicates where and how this data item is used and any supplementary information that is relevant to it.

The data dictionary entry begins as follows:
Name	telephone number
Aliases	none
Where used/how used	assess against set-up (output)
dial phone	(input)
description:
telephone number = [local number | long distance number] local number = prefix + access number long distance number = 1 + area code + local number area code = [800 | 888 | 561] prefix = *a three digit number that never starts with 0 or 1* access number = * any four number string *

Give the concept of data flow diagram & explain logical and physical DFD in detail.

• DFDs are categorized as either
  • logical
  • physical
• Logical DFDs
  • not concerned about how the system is or will be constructed
  • all functional features of the system are described independently of any computer platform

Advantages of Logical DFDs

• Better communication with users
• More stable systems
• Better understanding of the business by analysts
• Flexibility and maintenance
• Elimination of redundancies and easier creation of the physical model

Physical DFDs

• show how the system is or will be constructed
• Takes logical DFD/design to technology-specific details from which programming and system construction can take place (like platform-specific, etc.), naming specific physical media where data may be stored, etc.

Advantages of Physical DFDs

• Clarifying which processes are manual and which are automated
• Describing processes in more detail than logical DFDs
• Sequencing processes that have to be done in a particular order
• Identifying temporary data stores
• Specifying actual names of files and printouts
• Adding controls to ensure the processes are done properly

Comment: Software Quality Assurance is an umbrella activity

Software quality assurance (SQA) is an umbrella activity that is applied throughout the software process. SQA encompasses

•  A quality management approach,
• Effective software engineering technology (methods and tools),
•  Formal technical reviews that are applied throughout the software process,
• multitier testing strategy,
• Control of software documentation and the changes made to it,
• A procedure to ensure compliance with software development standards (when applicable), and
• Measurement and reporting mechanisms