Requirements Determination
Requirements Determination is the activity whereby information is gathered from many sources on what the system should do. A number of methods can be used in gathering the information depending upon the type of project.
Requirements Determination Outputs
Information collected. The information collected during the Requirements
Determination activity includes transcripts of interviews, responses to
questionnaires, notes from observations and the analysis of documents.
Current system's documentation. Documentation of the current system
includes forms, job descriptions, minutes of meetings, training manuals.
Computer-generated information. Computer-generated information includes
reports produced by the current system and CASE repository contents of
the current system.
Requirements Determination in Context
Requirements Determination is the first activity in the Analysis phase
of a System Development Life Cycle. It involves the systems analyst determining
what information is needed by the system. This information is then structured
using a number of views such as process, logic and data. Finally a set
of requirements is selected from the competing sets of requirements determined
and structured in the previous two activities. This set of requirements
forms the definition of the System for the Design phase. The requirements
determination activity may need to be revisited as deficiencies may be
discovered in later activities.
Developing a Strategy
An important aspect of the Requirements Determination activity is developing
a strategy for gathering the required information from the various sources
using the various methods available.
Traditional Collection Methods
There are four traditional methods for collecting system requirements:
· Interview individuals or groups regarding the operation and
issues of current systems, and the needs for future systems.
· Use questionnaires to gather facts regarding the system's
issues and requirements.
· Directly observe the system in operation to see how data is
handled and what information is needed.
· Analyse system documents to identify issues, policies and
rules.
Interviews
The initial interviews are normally conducted with the primary users
of the system. The aim of these interviews is to obtain the users' perspective
on what the current system does and what the new system requires.
Subsequent interviews should be conducted with representatives from a variety of groups that interact with or are interested in the development of the new system. The aim of these interviews is to obtain differing views on the requirements of the system.
Interviewing Guide
There are a number of important activities in ensuring the use of interviews
is successful:
· Plan the interview – identify the purpose of the interview
and the scope of the questions. Use a combination of open-ended and closed-ended
questions as appropriate (questions should not imply a right or wrong answer).
· Take notes – answers contain important information for the
systems analyst. If permitted record the interview, otherwise take notes
in an outline form and fill in the details later.
· Review within 2 days – clarify unclear points while the interview
is still fresh in everyone's mind. Ask additional questions as necessary.
Questionnaires
Questionnaires allow the systems analyst to get input from all users
without taking the time to personally interview each one of them. Sometimes
questionnaires are used when it is impossible to interview stakeholders,
such as customers, suppliers or others external to the organization.
Questionnaire Guide
There are a number of important activities in ensuring questionnaires
are used successfully:
· Choose a representative sample of respondents – there are a
number of ways of selecting the sample if surveying all users is impractical.
· Design questions to be extremely clear and logical – the questions
cannot be adjusted based on particular responses.
· Pre-test the questions – check the responses for reasonableness
and rephrase the questions as necessary.
Direct Observation
Directly observing workers interacting with the existing system is
often a rich source of information because users often perform their duties
differently from the way they describe them. This method is particularly
good for obtaining objective measures (quantitative data) of the interaction
with the system such as volume and speed as users do not always have an
accurate appreciation of what they do.
The limitation of this method is that the observation is for a fixed period and so may not include important events or variations to the standard procedure. In addition, bias can be introduced as users change their normal behaviour (become nervous, make mistakes, follow written procedures) when they are aware they are being monitored.
Document Analysis
Analysing business documents used by the organization to record data
or view data can help uncover the names and types of data that the new
system must accommodate. Furthermore, the rules of the business are often
described on business documents.
Useful Documents to Analyse
There are four basic groups of documents within an organization that
are useful to analyze:
· Work procedures – how a task should be performed is described,
including the data used or created by the task. Work procedures may reveal
a duplication of effort.
· Business forms – provide crucial information on the inputs
to the system. The forms are most useful when they contain actual data.
· Current system generated reports – provide information on
the outputs of the system and therefore the data that must be recorded
by the system in order to produce the outputs.
· Current system (computer-based) description – documentation
of the system such as flow charts, data dictionaries and models are useful
as a starting point for the analysis (however they are not always current).
New Requirements Collection Methods
There are a number of other methods for collecting system requirements
including Joint Application Design sessions, Group Support Systems, CASE
Tools and Prototyping. The aim of these methods and any other system requirements
collection method is to obtain a thorough set of information that describes
the current system and the differences required in the new system.
Process modelling is the activity performed by systems analysts that involves representing what occurs in the system using a diagrammatic technique. A DFD is the most common technique for process modelling. It is a network representation of the system used to track the flow of data through the system.
Process Modelling Outputs
Data Flow Diagrams. Generally a number of DFDs are produced including:
· the highest level DFD – called a Context DFD or more simply
a Context Diagram,
· current Physical DFDs – ranging in number depending upon the
complexity of the system (normally two levels as a minimum),
· current Logical DFDs – more detailed than the Physical DFDs,
and
· new Logical DFDs – include the new requirements.
Data Descriptions.
Each component on every DFD is described, and the descriptions are
recorded in a Data Dictionary. These days a CASE Repository is more likely
to be used than a Data Dictionary.
Representation Standards
There are a number of symbol sets used for depicting DFDs, however
most are simply variations of the Gane & Sarson or DeMarco & Yourdon
"standards" depicted below.
The introduction of Case Tools also brought about additional variations to the symbols.
Naming Requirements for Symbols
Processes represent actions performed on data that transform, store
or distribute the data. The name given to a Process must indicate what
occurs to produce the output data. Use a verb and noun combination eg Calculate
Student Grade and avoid meaningless names eg Process Student Data.
Data Stores represent data waiting to be used. The name given to a Data Store must reflect the type of data that is stored. Use a noun eg Subject. Only in a Physical DFD may the Data Store name also include the type of storage eg Student File.
External Entities represent the "things" outside the system that provide data to the system or receive data from the system or both. They were originally referred to as origin and destination, then sources and sinks, and now External Entities. The name given to an External Entity must indicate who or what, sends data to the system or receives data from the system or both. Use a noun eg School Administration.
Data Flows represent the data moving in the system between other elements, eg from a Process to a Data Store. Data flows can represent a single data item (eg Student Name) or a number of data items (eg Student Details). The name given to a Data Flow must reflect the aggregation of the individual elements of the Data Flow. Use a noun or noun and adjective combination eg Verified Student Name.
Approaches to Constructing Data Flow Diagrams
There are two basic approaches to constructing DFDs for a system: the
top-down approach and the bottom-up approach.
The top-down approach commences with a Context Diagram and then uses functional decomposition to break up the system into its major functions. Processes on the Level-0 DFD represent these functions. Then functional decomposition is again used to break up each Process, as required, into a number of activities. Processes on the Level-1 DFDs represent these activities. Functional decomposition of Processes on a DFD continues until each Process cannot reasonably be decomposed any further. Not all Processes on a DFD need to be decomposed to the next level.
The bottom-up approach commences with the construction of a DFD (generally for part of the system) at a very detailed level and then uses grouping of related Processes to create higher-level Processes that are placed on a DFD one level up. Grouping of Processes is generally performed when the number of Processes on a DFD exceeds approximately seven. Grouping of Processes continues until one Process representing the system is created. This Process is placed on the highest level DFD, the Context Diagram.
Whichever approach is used, all DFDs including the Context Diagram must be balanced with the DFDs at the next level up and down the hierarchy of DFDs as explained in a later section.
Top-Down Approach
The following example illustrates the construction of DFDs using the
top-down approach. To keep the example simple the scenario involves a Video
Rental System that only deals with creating new members and renting videos
requested by its members.
Drawing a Context Diagram
The following is a description of the steps in drawing a Context Diagram
for a system.
1. To create a Context Diagram start with a single Process that represents the entire system. In this case and only this case the Process is named after the system, rather than the function performed by the Process. Draw a Process with the number zero.
2. Draw the External Entities.
3. Start with one of the External Entities and draw the Data Flows from that External Entity to the system and the Data Flows from the system to that External Entity.
4. Continue with drawing in the Data Flows for each remaining External Entity until the Context Diagram is completed.
The data elements that make up each Data Flow would be described in the Data Dictionary, eg Rental Request comprises Member Details and many Video Titles.
Drawing a Level-0 Data Flow Diagram
The following is a description of the steps in drawing a Level-0 DFD
from the Context Diagram for a system.
1. To create the Level-0 DFD start with the Process on the Context Diagram that represents the entire system and identify the major functions performed by that system. Draw numbered Processes to represent each major function.
2. From the Context Diagram select an External Entity and a Data Flow from that External Entity to Process 0. Draw the External Entity and allocate the Data Flow to the relevant Process. Generally, choose the External Entity and related Data Flow that in a chronological sense is the first to interact with the system.
3. For the Data Flow into a Process determine the data that comes out of that Process as a result of the transformation that occurs within the Process. Data Flows back to the External Entity or into a Data Store or into another Process are drawn as appropriate. If you draw a Data Flow going into another Process, then repeat this step for that Data Flow.
4. Continue with drawing an External Entity, allocating its Data Flows to the relevant Processes, determining the data that comes out of the Process and including the appropriate Data Flows in the DFD until all the External Entities and their Data Flows have been dealt with.
Data coming out of a Process must come from the Data Flows going into the Process or be internally generated by the Process. Therefore, for any transformation, if additional data is required, the necessary Data Flows are identified and added to the DFD (eg Member Details for Process 2.0 Rent Videos).
Drawing a Level-1 DFD by Decomposing a Level-0 DFD Process
The following is a description of the steps in drawing a Level-1 DFD
from a Process on a Level-0 DFD.
1. To create a Level-1 DFD start with a Process on the Level-0 DFD (eg Process 2.0) and identify the major activities performed by that Process. Draw numbered Processes to represent each major activity. (Note the numbering is taken from the higher-level Process.)
2. Select a Data Flow going into the Level-0 DFD Process and allocate it to the relevant Level-1 DFD Process. Generally, choose the Data Flow that in a chronological sense is the first to interact with the Level-0 DFD Process.
3. For the Level-1 DFD Process determine the data that comes out of the Process as a result of the transformation that occurs within the Process and any additional data required to perform the transformation. Data Flows to or from External Entities, Data Stores, or other Processes are drawn on the DFD as appropriate. (Note the External Entities themselves are not drawn on DFDs below Level-0.)
4. If data is passed to another Process by a Data Flow, repeat the previous step for that Data Flow. Continue with selecting a Data Flow going into the Level-0 DFD Process, allocating it to the relevant Level-1 DFD Process, determining the data that comes out of that Process, and including the appropriate Data Flows and Data Stores in the Level-1 DFD. These steps are repeated until all the Data Flows from the Level-0 DFD Process have been dealt with.
Bottom-Up Approach
The following example illustrates the construction of DFDs using the
bottom-up approach. To keep the example simple the following description
of a University Enrolment System is used:
1. To create the lower-level DFD start by analysing the system description looking for External Entities, Data Flows, Processes and Data Stores. Generally, choose an External Entity and Data Flow that in a chronological sense are the first to interact with the system (Students send in an application form) and include a Process to transform that Data Flow (university checks that the course is available...). Draw the External Entity, Data Flow and Process.
2. Use the system description to determine the data that comes out of that Process as a result of the transformation that occurs within the Process (application is accepted ... application is rejected) and draw the appropriate Data Flows. If additional data is required for the transformation, draw the identified Data Flows (and possibly Data Stores).
3. Select a Data Flow coming out of the Process (eg Accepted Application) and using the system description draw a Process to transform that Data Flow (student is then enrolled in the course). Repeat the previous step for that Process.
4. Continue with selecting each remaining Data Flow coming out of a Process, including another Process to transform the Data Flow, determining the data that comes out of the Process and adding the appropriate Data Flows to the DFD until all the Data Flows have been dealt with.
External Entities (and Data Stores) can be repeated on a DFD to improve the look of the diagram if they are noted as a copy (eg diagonal line in corner).
5. Repeat all of the above activities until the entire system description has been modelled on the DFD.
Grouping Processes to Create a Higher-Level DFD
The following is a description of the steps in grouping Processes to
create a higher-level diagram.
1. To create a higher-level DFD start with the Processes on the lower-level DFD and determine any logical groupings. (Normally this is done when there are more than seven Processes on a DFD, however to illustrate the procedure two of the four Processes will be grouped.)
2. Replace the grouped Processes with a single Process that combines all the transformations that occur in the original Processes. Any Data Flows between the grouped Processes do not appear on the higher-level DFD, nor do any Data Stores (and related Data Flows) that are only used by the grouped Processes.
3. Modify the lower-level DFD to retain only the grouped Processes and their related Data Flows and Data Stores. Renumber Processes on both DFDs as required, and rename Processes on the higher-level DFD as required.
Higher-Level DFD Lower-Level DFD
4. Continue with determining any logical groupings, replacing the grouped Processes with a single Process, modifying the lower level DFD to retain only the relevant Data Flows and Data Stores, renumbering and renaming appropriate Processes on both DFDs until only one Process remains on a DFD. This higher-level DFD is the Context Diagram and the single Process represents the entire system.
General Rules for Developing DFDs
All objects of the same type on a DFD must have unique names (eg all
External Entities must be uniquely named). Some texts allow Data Flows
with the same name on a DFD; however, this should be a rare occurrence
as it indicates exactly the same data travelling in two different places.
DFDs are generally drawn from left to right with Processes numbered according to their occurrence in chronological sense.
Process Rules
Processes must have both inputs and outputs and they must differ, that
is some transformation must occur to the inputs to produce the outputs.
Data Store Rules
A Data Flow going into a Data Store must come from a Process and a
Data Flow coming out of a Data Store must go into a Process.
A Data Flow going into a Data Store must update data (not simply be
the key for obtaining data from the Data Store).
Data Stores are not represented on a DFD when all of their Data Flows
go into and/or come from a single Process. The exception is the lowest
level DFD.
External Entity Rules
A Data Flow going to an External Entity must come from a Process and
a Data Flow coming from an External Entity must go into a Process.
Data Flow Rules
A Data Flow has only one direction of flow between two objects on a
DFD. (Whilst some texts use bi-directional arrows, this is not generally
accepted.)
A Data Flow cannot connect to the same object from which it originates.
Balancing a Set of DFDs
Balancing a set of DFDs means conserving the input data and output
data of a Process from a particular DFD level to the next level when that
Process is decomposed. Generally, all the Data Flows going into and out
of a Process on a DFD are repeated on the next level DFD. However, a composite
Data Flow on one level can be matched against a number of Data Flows on
a lower level, if all the data represented by the composite Data Flow is
also represented across the other Data Flows.
Level-1 DFD (Incomplete) Level-2 DFD (Incomplete)
Converting a Physical DFD into a Logical DFD
Converting a Physical DFD into a Logical DFD involves removing the
physical aspects of the system such as physical names of Data Stores (eg
Student File to Student) and Data Flows (eg Application Form to Application).
In addition, the conversion involves combining Processes that occur at
the same time, only move or reorganise data, are non-essential, or relate
to physical aspects of the system (eg combining Check Course List and Sign
Course List into Verify Courses). The conversion can also involve turning
transient Data Stores into Data Flows.
Logical data modelling is the design activity performed by systems analysts that involves representing the data required in a format that is close to the physical implementation requirements. It is a bottom-up activity that generally starts with the actual data requirements on the forms and reports used in an information system.
Logical Data Modelling Design Outputs
Set of Normalized Relations.
A set of normalized Relations is produced to reflect the complete data
requirements of the system.
Updated Data Dictionary.
Each Relation and Attributes within the Relations are described, and
the descriptions added to the existing Data Dictionary. There is generally
overlap between the Attributes on an E-R Diagram and those in the Relational
Data Model.
Logical Data Modelling Process
The process of producing a logical data model for the system involves
four basic steps
· a logical data model is created for each user view,
· the logical data models for each view are consolidated into
one logical data model,
· the conceptual data model is converted into a logical data
model, and
· the consolidated logical data model is compared to and combined
with the converted logical data model to produce a single logical data
model for the system.
Relations
Relations are the table-like structures (with rows and columns) used
to represent the data. The notation for Relations consists of the Relation
name followed by the names of the Attributes of the Relation in brackets.
The Primary Key of the Relation is underlined and generally appears at
the start of the Relation.Relation
Properties
Relations have a number of properties that separate them from a table
of data including
· each row in the Relation is distinct form all other rows,
· each Attribute in the Relation is distinct from all other
Attributes,
· the values for each Attribute come from the same domain, and
· the values for each Attribute are simple and single-valued.
Relation Inconsistencies
There are three operations that can be performed on a Relation that
may result in inconsistencies in the data in a Relation. The operations
change the data in a Relation through inserting a new row, updating the
value of an Attribute in one or more rows, and deleting rows. The logical
data modelling activity attempts to eliminate the likelihood of inconsistencies
occurring by developing well-structured Relations that have been normalized.
Normalization
Normalization is the process of producing a logical data model for
the system that contains well-structured Relations and thereby avoids data
inconsistencies as a result of operations being performed on the data.
Normalization involves decomposing Relations in a series of steps until
the resulting Relations are all well-structured Relations. The steps correspond
to a normal form starting with the First Normal Form (1NF) and continuing
up to the Fifth Normal Form (5NF). Testing each Relation against the rules
for 1NF, 2NF and 3NF is the most common form of Normalization. The latter
normal forms are not generally applied in practice.
Normal Form Tests
The test for 1NF is to check that all Attributes have a single value,
which is one of the properties of a Relation. The test for 2NF is to check
that all non-key Attributes are fully functionally dependent on the primary
key of the Relation. The test for 3NF is to check that there are no transitive
dependencies between the non-key Attributes. When Relations do not satisfy
the normal form test, they are generally decomposed into a number of Relations,
which are then individually tested. The normal forms build on each other
such that only when Relations have been assessed as 1NF are they are tested
for 2NF, and only when they have been assessed as 2NF are they tested for
3NF.
Foreign Keys
An important aspect of decomposing Relations into smaller normalized
Relations is to maintain the original links between the Attributes. This
is done with the introduction of a Foreign Key, the same Attribute that
is a Primary Key in a Relation, into another Relation.
Converting E-R Diagrams
The process to create a Relational Data Model from an E-R Diagram involves
a number of steps
· the Entities and their Attributes are represented as Relations,
· the Relationships between Entities including Attributes on
the Relationships are represented as Relations, and
· all of the Relations produced are normalized.
Entities and Attributes
Converting an Entity and its Attributes into a Relation is a simple
process of using the Entity name for Relation name and using the Primary
Key and Attribute names from the Entity as the Primary Key and Attribute
names for the Relation.
A Weak Entity has an additional requirement and that is the introduction of the Primary Key of the related Entity in addition to the Primary Key of the Weak Entity as part of the composite Primary Key of the Relation.
Relationships and Attributes
Converting a Relationship and its Attributes is a more complicated
process as the degree and cardinality of the Relationship affect the manner
in which it is converted. There are two general approaches in the conversion
· the Primary Key of one of the Entities involved in the Relationship
is included as a Foreign Key in the Relation for the other Entity, and
· a new Relation is created using the Primary Key of all Entities
involved in the Relationship as the composite Primary Key for the new Relation.
Specific combinations of degree and cardinality use one or other of the approaches identified.
Click on this link below to download a lecture on logic modelling. The lecture is rather long (15 pages) and contains several graphics. It was easier for me to provide a link to the file for downloading than to insert it here in the lecture materials and paste in all of the graphics.