Chapter 6 - Specifying requirements: analysis and design in the

structured systems analysis paradigm

Introduction
 During the requirements elicitation phase of the life cycle, the resulting requirements must
be written as a requirements specification. The functional requirements, in particular, have
to be written so that they can be understood by the technical staff from both the system
developers and procurers. Within structured systems analysis (SSA) we can distinguish
between three types of modelling that may be used to gain a better understanding of the
system to be built (Pressman, 2005):
• functional modelling
• data modelling
• behavioural modelling.
 Structured systems analysis provides a number of notation techniques in order to support
requirements analysis.

DFD – Data Flow Diagrams

(Study guide)

 Functional modelling is typically supported through the use of a data flow diagram (DFD).
The data flow diagram gives information on how data is transformed as it ‘flows’ through the
system, and it gives information on the kind of processes that transform the data within a
system. It is very important that you understand that data flow diagrams merely show how
data moves through the system, and how the data is transformed by processes. The data
flow diagram does not model the flow of control through the system (i.e. it is not concerned
with the order in which processes are carried out and therefore does not consider the
conditions that have to be fulfilled in order for a transformation to be carried out).
 The following notation is used within DFDs:
• External entities are represented by a box. An external entity can be a source of
system inputs or a sink for system outputs. For example, an external entity of a
system could be a person or organisation outside the context of the system that is
an originator or receiver of system data.
• Processes (transforms) perform some form of transaction on the data flowing
through the system and are represented as circles. For example, the registration of a
job applicant could be such a process.
• Data flows within a DFD are represented as arrows that connect processes to each
other or to external entities. An example of such a data flow might be a registration
form.
• A data store is a repository of data and is represented as two horizontal lines.
 An advantage of a DFD is its graphical representation, which makes it not only accessible to
the analyst, but also to the non-expert system user. Furthermore, DFDs allow for levelled
representation. A level-0 DFD (also referred to as the context diagram) shows a system at its
most general level as a single process with its incoming and outgoing data flows. An example
of a level-0 DFD of a basic payroll system is given in Figure 6.1.
 The input of the payroll system consists of the employee’s personal data such as name,
address, tax code etc. and the amount of time worked. The output produced consists of the
pay cheque for the employee and formatted accounting information that is distributed
within the finance department for accounting purposes. The exact details of individual data
flows is described within a data dictionary.
 Note that in Figure 6.1 the employee is represented twice. This is not really necessary, but is
practised here to separate input and output merely to support better readability.
 Once the level-0 diagram has been created, more detail about the system is introduced at
level-1. This process is often referred to as refinement.
 During the refinement of a DFD, processes are broken down into smaller processes and the
information flows between them. It is very important that overall the incoming and outgoing
data flows remain the same at different levels of refinement. An example of a possible
refinement of the level-0 DFD in Figure 6.1 is presented in Figure 6.2.
  Within this DFD the processes 1, 3 and 4 cannot be divided any further and therefore are
referred to as primitive (Hamlet and Maybee 2001). They represent simple transforms with
single incoming and outgoing flows. However, process 2 is more complex and should be
divided further in a level-2 diagram.
 DFD refinement
• During the refinement of a DFD:
 Processes are broken down into smaller processes and the information
flows between them
 It is very important that the overall incoming and outgoing data flows
remain the same at different levels of refinement
 Processes that cannot be refined further are called primitives. These
normally have one input and one output.
(Pressman)

 Although data flow-oriented modeling is perceived as an outdated technique by some

software engineers, it continues to be one of the most widely used requirements analysis
notations in use today.
 Although the data flow diagram (DFD) and related diagrams and information are not a
formal part of UML, they can be used to complement UML diagrams and provide additional
insight into system requirements and flow.
 The DFD takes an input-process-output view of a system. That is, data objects flow into the
software, are transformed by processing elements, and resultant data objects flow out of
the software.
 Data objects are represented by labeled arrows, and transformations are represented by
circles (also called bubbles).
 The DFD is presented in a hierarchical fashion. That is, the first data flow model (sometimes
called a level 0 DFD or context diagram) represents the system as a whole. Subsequent data
flow diagrams refine the context diagram, providing increasing detail with each subsequent
level
 The purpose of data flow diagrams is to provide a semantic bridge between users and
systems developers – Kenneth Kozar
 Creating a data flow diagram
o The data flow diagram enables you to develop models of the information domain
and functional domain. As the DFD is refined into greater levels of detail, you
perform an implicit functional decomposition of the system. At the same time, the
DFD refinement results in a corresponding refinement of data as it moves through
the processes that embody the application.
o A few simple guidelines can aid immeasurably during the derivation of a data flow
o diagram:
1. the level 0 data flow diagram should depict the software/system as a single
bubble;
2. primary input and output should be carefully noted;
3. refinement should begin by isolating candidate processes, data objects, and
data stores to be represented at the next level;
4. all arrows and bubbles should be labeled with meaningful names;
5. information flow continuity must be maintained from level to level,2 and
6. one bubble at a time should be refined. There is a natural tendency to
overcomplicate the data flow diagram. This occurs when you attempt to
 show too much detail too early or represent procedural aspects of the
software in lieu of information flow.
 The refinement of DFDs continues until each bubble performs a simple function. That is,
until the process represented by the bubble performs a function that would be easily
implemented as a program component. In Chapter 8, I discuss a concept, called cohesion,
that can be used to assess the processing focus of a given function. For now, we strive to
refine DFDs until each bubble is “single-minded.”

Entity Relationship Diagrams

 ER-diagrams:
o Data objects are any composite information that must be understood by software
(e.g. a thing or an event). Data objects are represented as boxes.
o Attributes define the properties of a data object and are represented as circles. One
or more attributes are defined as the primary key. The primary key defines an
object.
o Relationships connect the data objects and are represented in the form of arrows or
diamonds. Object-relationship pairs are bi-directional. We can distinguish between
1:1, 1:N and M:N relationships.
Conceptual modelling by means of the entity relationship (E-R) model
 A conceptual model represents a real-life system by means of a (limited) set of semantic
concepts (e.g. entity, property, relationship).
 It is very useful to view the world through only these concepts, because:
o the representation is more systematic,
o Less ambiguous and clearer,
 and thus it is better for our purpose than the description of the real-world system in natural
language. We can understand the real-world system if it is conceptually modelled.
 Conceptual design involves addressing the following questions:
o What are the ‘entities’ and ‘relationships’ in the enterprise?
o What information about these entities and relationships should we store in the
database?
o What are the ‘integrity constraints or business rules’ that hold?
 A database ‘schema’ in the E-R model can be represented pictorially by E-R diagrams (or
ERDs). The E-R model cannot be implemented directly but we can map an E-R diagram into a
relational schema. Mechanisms (or algorithms) exist for the ‘translation’ of the semantic
concepts into the symbolic objects of the relational model (for instance, an entity
corresponds to a relation; a property to an attribute, etc.). These mechanisms or mapping
algorithms are presented later in this chapter.
 Actually, by not being dependent upon a symbolic representation, a conceptual model can
be carried from one logical model to another (relational, hierarchical) and consequently
from one DBMS to another.
 The entity-relationship (E-R) model is the most popular conceptual modelling approach. Its
main concepts are:
o Entity
o Property
o Relationship
o Type/subtype.
 The success of this technique stems not only from its limited but powerfully expressive set of
concepts, but also from the accompanying diagramming technique. The following
paragraphs introduce each concept in turn, together with the way you portray it using this
model.

Representing E-R diagrams

 E-R Model notation has been revised many times since Chen introduced it in 1976. In this
subject guide I use Unified Modelling Language (UML) notation to represent Entity
Relationship (E-R) diagrams. This notation is also used by Connolly and Begg (2010).
 However, in other books you may find other notations in use (e.g. Chen or Crow’s Feet).
Initially you may find these different notations confusing but if you look closer you will
notice that the basic concepts behind the E-R model remain the same.
 In the examination, if asked to draw an E-R model, you can use either UML notation or Chen
or Crow’s Feet Notation. Also, to keep the E-R diagrams simple, it is better if you depict
entities without their attributes. Attributes can be listed separately. The choice of notation
will not have an impact on your mark (marks will be awarded for the correctness4 of your
model).
Entities
 According to its original definition by Chen (1976), an entity is: ‘A thing that can be distinctly
identified’. This definition is very loose; almost anything can be an entity: a car, a house, a
tree, a person, a dream, an idea, a friendship, a craving, a number… it is up to you to decide
what is and what is not an entity in a real-life system. However, in the context of database
systems we regard an entity as something we need to store information about. A distinction
can be made between entities classifying them as:
o Weak, in that their existence depends on the existence of other entities (e.g. the
existence of next-of-kin in the company database depends on the existence of the
employee).
o Regular or strong: that is, an entity that is not weak.
 In some notations a strong entity is represented diagrammatically, by means of a rectangle
labelled with the entity’s name. For a weak entity the rectangle is doubled. In UML notation
(used in Figure 13.2) this distinction is not represented diagrammatically. Unless you are
specifically asked to do so, you do not need to specify entity types in an E-R Diagram (e.g.
when an examination question asks you to produce an E-R Diagram for a case study).
However, you need to be aware of this distinction between entities as it has implications for
the design of the database.
 We also need to make a distinction between an entity as a type and an entity as an instance.
This distinction is illustrated here via an example: Lecturer is a type entity (having properties
like name, date of birth, address, etc., but no explicit values for them), whereas ‘John Baker,
born on 1/04/1966…’ is a particular instance of the type Lecturer. Note that, in the context
of

database design, we usually concentrate on entities as types (not instances).

Relationship Types
 Relationship type is a set of meaningful associations among entity types.
o A relationship type is a set of associations between one or more participating entity
types. Each relationship type is given a name that describes its function. An example
of a relationship type shown in Figure 11.1 is the relationship called POwns, which
associates the PrivateOwner and PropertyForRent entities. As with entity types and
entities, it is necessary to distinguish between the terms ‘relationship type’ and
‘relationship occurrence’.

 Relationship occurrence is a uniquely identifiable association, which includes one

occurrence from each participating entity type.
o A relationship occurrence indicates the particular entity occurrences that are
related. Throughout this book, we use the terms ‘relationship type’ or ‘relationship
occurrence’. However, as with the term ‘entity’, we use the more general term
‘relationship’ when the meaning is obvious.
o Consider a relationship type called Has, which represents an association between
Branch and Staff entities, that is Branch Has Staff. Each occurrence of the Has
relationship associates one Branch entity occurrence with one Staff entity
occurrence.
 Note that we represent each Branch and Staff entity occurrences using values for the
their primary key attributes, namely branchNo and staffNo. Primary key attributes
uniquely identify each entity occurrence and are discussed in detail in the following
section.
 If we represented an enterprise using semantic nets, it would be difficult to
understand due to the level of detail. We can more easily represent the relationships
between entities in an enterprise using the concepts of the Entity–Relationship (ER)
model. The ER model uses a higher level of abstraction than the semantic net by
 combining sets of entity occurrences into entity types and sets of relationship
occurrences into relationship types.

 Diagrammatic representation of relationships types

o Each relationship type is shown as a line connecting the associated entity
types, labelled with the name of the relationship. Normally, a relationship is
named using a verb (for example, Supervises or Manages) or a short phrase
including a verb (for example, LeasedBy).
o Again, the first letter of each word in the relationship name is shown in upper
case. Whenever possible, a relationship name should be unique for a given
ER model. A relationship is only labeled in one direction, which normally
means that the name of the relationship only makes sense in one direction
(for example, Branch Has Staff makes more sense than Staff Has Branch). So
once the relationship name is chosen, an arrow symbol is placed beside the
name indicating the correct direction for a reader to interpret the
relationship name (for example, Branch Has Staff) as shown in Figure 11.5.
Degree of Relationship Types
Unary

Binary

Ternary
Quaternary

Relationships
 Chen (1976) defined a relationship as ‘an association among entities’.
 For instance, between lecturer and course we can identify the ‘teaches’ relationship. The
entities involved in a relationship are called the participants in that relationship. Note that,
in the context of database design, we identify relationships between type entities; therefore
we identify type relationships (as opposed to instance relationships).
 The participation of a type entity E in a relation type R is said to be total if any instance of E
participates at least in one instance of R. For example, the participation of lecturer ‘belongs
to’ Academic Department is total, since any lecturer must belong to an Academic
Department. The number of entities participating in a relationship represents the degree of
the relationship.
 There are three important kinds of relationships reflecting cardinality constraints (note that
we have given classifications for binary relations only, in other words of degree 2 of the kind
E1 R E2, where entity 1 is in relation R with entity 2):
o One-to-one: for any instance e1 of E1 there is a single instance e2 of E2, such that e1
R e2 and vice-versa (e.g. ‘has’ between ‘Lecturer’ and ‘room’).
o One-to-many: for an instance e1 of E1 there might be more than one instance of E2,
e21, e22,…, e2n, such that e1 R e21, e1 R e22,…, e1 R e2n, but for any instance e2 of
E2, there is only a single instance e1 of E1 such that e1 R e2 (e.g. ‘belongs to’
between ‘Lecturer’ and ‘Academic Department’).
o Many-to-many: for an instance e1 of E1 there might be more than one instance of
E2, e21, e22, …, e2n, such that e1 R e21, e1 R e22, …, e1 R e2n, and vice-versa; e.g.

‘teaches’ between ‘Lecturer’ and ‘course’.

 In UML notation, a relationship is graphically represented by a line between the participating
entities. The three kinds of relationships are labelled 1:1, 1:* and *:*, respectively (see
Figure 13.2).

One-to-One (1:1) Relationships

 Consider the relationship Manages, which relates the Staff and Branch entity types. Figure
11.14(a) displays two occurrences of the Manages relationship type (denoted r1 and r2)
using a semantic net. Each relationship (rn) represents the association between a single
 Staff entity occurrence and a single Branch entity occurrence. We represent each entity
occurrence using the values for the primary key attributes of the Staff and Branch entities,
namely staffNo and branchNo.
 Determining the multiplicity
 o Determining the multiplicity normally requires examining the precise relationships
between the data given in a enterprise constraint using sample data. The sample
data may be obtained by examining filled-in forms or reports and, if possible, from
discussion with users. However, it is important to stress that to reach the right
conclusions about a constraint requires that the sample data examined or discussed
is a true representation of all the data being modelled.

In

Figure 11.14(a) we see that staffNo SG5 manages branchNo B003 and staffNo SL21 manages
branchNo B005, but staffNo SG37 does not manage any branch. In other words, a member of staff
can manage zero or one branch and each branch is managed by one member of staff. As there is a
maximum of one branch for each member of staff involved in this relationship and a maximum of
one member of staff for each branch, we refer to this type of relationship as one-to-one, which we
usually abbreviate as (1:1).

 Diagrammatic representation of 1:1 relationships

o An ER diagram of the Staff Manages Branch relationship is shown in Figure 11.14(b).
To represent that a member of staff can manage zero or one branch, we place a
‘0..1’ beside the Branch entity. To represent that a branch always has one manager,
we place a ‘1..1’ beside the Staff entity. (Note that for a 1:1 relationship, we may
choose a relationship name that makes sense in either direction.)
One-to-Many (1:*) Relationships
 Consider the relationship Oversees, which relates the Staff and PropertyForRent entity
types. Figure 11.15(a) displays three occurrences of the Staff Oversees PropertyForRent
relationship type (denoted r1, r2, and r3) using a semantic net. Each relationship (rn)
represents the association between a single Staff entity occurrence and a single
PropertyForRent entity occurrence. We represent each entity occurrence using the values
for the primary key attributes of the Staff and PropertyForRent entities, namely staffNo and

propertyNo.
  Determining the multiplicity
o In Figure 11.15(a) we see that staffNo SG37 oversees propertyNos PG21 and
PG36, and staffNo SA9 oversees propertyNo PA14 but staffNo SG5 does not
oversee any properties for rent and propertyNo PG4 is not overseen by any
member of staff. In summary, a member of staff can oversee zero or more
properties for rent and a property for rent is overseen by zero or one member of
staff. Therefore, for members of staff participating in this relationship there are
many properties for rent, and for properties participating in this relationship
there is a maximum of one member of staff. We refer to this type of relationship
as oneto-many, which we usually abbreviate as (1:*).
 Diagrammatic representation of 1:* relationships
o An ER diagram of the Staff Oversees PropertyForRent relationship is shown in
Figure 11.15(b). To represent that a member of staff can oversee zero or more
properties for rent, we place a ‘0..*’ beside the PropertyForRent entity. To
represent that each property for rent is overseen by zero or one member of
staff, we place a ‘0..1’ beside the Staff entity. (Note that with 1:* relationships,
we choose a relationship name that makes sense in the 1:* direction.)
o If we know the actual minimum and maximum values for the multiplicity, we can
display these instead. For example, if a member of staff oversees a minimum of
zero and a maximum of 100 properties for rent, we can replace the ‘0..*’ with
‘0..100’.

Many-to-Many (*:*) Relationships

Consider the relationship Advertises, which relates the Newspaper and PropertyForRent entity
types. Figure 11.16(a) displays four occurrences of the Advertises relationship (denoted r1, r2, r3,
and r4) using a semantic net. Each relationship (rn) represents the association between a single
Newspaper entity occurrence and a single PropertyForRent entity occurrence. We represent each
entity occurrence using the values for the primary key attributes of the Newspaper and
PropertyForRent entity types, namely newspaperName and propertyNo.

 You would read the relationships in Figure 13.2 in the following way: lecturer has one and
only one room and room can be associated with none or only one lecturer. Lecturer belongs
to one and only one department but department has one or more lecturers. Lecturer
teaches one or more courses and course must be taught by one or more lecturers. You will
Enhanced Entity relationship
 The E-R model is sufficient to represent traditional database applications. To cater for the
additional concepts present in the newer databases, the Enhanced entity relationship model
has been created. These handle the concepts of types,
o Supertypes and subtypes,
o Inheritance, (not important)
o Specialisation and (not important)
o Generalisation. (not important)
 The concept of specialization/generalization is associated with special types of entities
known as superclasses and subclasses, and the process of attribute inheritance. We begin
this section by defining what superclasses and subclasses are and by examining
superclass/subclass relationships. We describe the process of attribute inheritance and
contrast the process of specialization with the process of generalization. We then describe
the two main types of constraints on superclass/subclass relationships called participation
and disjoint constraints. We show how to represent specialization/generalization in an
Enhanced Entity–Relationship (EER) diagram using UML.
 A type is defined by the common properties of a set of entities. Therefore any instance
entity is of at least one type, and it belongs to a type entity. Note that an instance entity can
be of a more than one type. E.g. In the type hierarchy illustrated, John is a clerk, but he is
also an employee and a person.

 In the previous illustration, the Person was a supertype (superclass) and the Employee a
subtype (subclass). Similarly, The Employee is a supertype for the two subtypes Clerk and
Engineer. A subtype inherits all the properties of its supertypes.
 Superclasses and Subclasses
o As we discussed in Chapter 11, an entity type represents a set of entities of the same
type such as Staff, Branch, and PropertyForRent. We can also form entity types into
a hierarchy containing superclasses and subclasses.
o Superclass An entity type that includes one or more distinct subgroupings of its
occurrences, which require to be represented in a data model.
o Subclass A distinct subgrouping of occurrences of an entity type, which require to be
represented in a data model.
o Entity types that have distinct subclasses are called superclasses. For example, the
entities that are members of the Staff entity type may be classified as Manager,
SalesPersonnel, and Secretary. In other words, the Staff entity is referred to as the
superclass of the Manager, SalesPersonnel, and Secretary subclasses. The
relationship between a superclass and any one of its subclasses is called a
superclass/subclass relationship. For example, Staff/Manager has a
superclass/subclass relationship.
 Superclass/subclass relationships
o Each member of a subclass is also a member
of the superclass. In other words, the entity
in the subclass is the same entity in the
superclass, but has a distinct role. The
relationship between a superclass and a
subclass is one-to-one (1:1) and is called a
superclass/subclass relationship (see Section
 11.6.1). Some superclasses may contain overlapping subclasses, as illustrated by a
member of staff who is both a Manager and a member of Sales Personnel. In this
example, Manager and SalesPersonnel are overlapping subclasses of the Staff
superclass. On the other hand, not every member of a superclass need be a member
of a subclass; for example, members of staff without a distinct job role such as a
Manager or a member of Sales Personnel.
o We can use superclasses and subclasses to avoid describing different types of staff
with possibly different attributes within a single entity. For example, Sales Personnel
may have special attributes such as salesArea and carAllowance. If all staff attributes
and those specific to particular jobs are described by a single Staff entity, this may
result in a lot of nulls for the job-specific attributes. Clearly, Sales Personnel have
common attributes with other staff, such as staffNo, name, position, and salary.
However, it is the unshared attributes that cause problems when we try to represent
all members of staff within a single entity. We can also show relationships that are
only associated with particular types of staff (subclasses) and not with staff, in
general. For example, Sales Personnel may have distinct relationships that are not
appropriate for all staff, such as SalesPersonnel Uses Car.
o To illustrate these points, consider the relation called AllStaff shown in Figure 12.1.
This relation holds the details of all members of staff no matter what position they
hold. A consequence of holding all staff details in one relation is that while the
attributes appropriate to all staff are filled (namely, staffNo, name, position, and
salary), those that are only applicable to particular job roles are only partially filled.
For example, the attributes associated
o with the Manager (mgrStartDate and bonus), SalesPersonnel (salesArea and
carAllowance), and
o Secretary (typingSpeed) subclasses have values for those members in these
subclasses. In other words, the attributes associated with the Manager,
SalesPersonnel, and Secretary subclasses are empty for those members of staff not
in these subclasses.
o There are two important reasons for introducing the concepts of superclasses and
subclasses into an ER model. Firstly, it avoids describing similar concepts more than
once, thereby saving time for the designer and making the ER diagram more
readable. Secondly, it adds more semantic information to the design in a form that is
familiar to many people.
o For example, the assertions that ‘Manager IS-A member of staff’ and ‘flat IS-A type
of property’, communicates significant semantic content in a concise form.
State-transition diagrams
 State-transition diagrams (STD) show how the system behaves as a consequence of some
external stimuli. For this purpose the STD represents the state of the system and the
transitions into different states when an external event happens.
 The structure of the data items within these models may be described in more detail within
the data dictionary. Similarly, the models will contain a more detailed description of the key
processes taking place.
 The STD represents:
o • The state of the system, and
o • The transitions into different states …
 … when an external action occurs
Undertaking design using the structured systems analysis paradigm
(Study guide)

 Within software design the system requirements are translated into a detailed definition of
how the system can be implemented in computer executable code. The design process is a
creative one and, although methods and guidelines are helpful, judgment and flair on the
part of the software engineer are still required to design a software system. Within the
structured approach to systems analysis, the design process transforms the functional, data
and behavioural model created within the requirements analysis phase. It can be divided
into (Pressman, 2005):
o data design
o architectural design
o interface design
o component-level design.
 Data design
o Data design transforms the data model into the data structures that will be required
to implement the system.
 Architectural design
o Architectural design is concerned with determining the key modules that will exist in
the system and the links between these modules. These key modules describe all
the key functions that the system will have to provide.
o Structure charts
 A common technique used within architectural design is structured design.
The data flow diagram created during the analysis phase builds the basis for
this technique. Within structured design the DFD, which has been refined to
a level at which all processes are primitive, is translated into a structure
chart. The structure chart provides information about the organisation of
the modules that eventually form the system and about the data that is
passed back and forward between these modules.
 In order to construct a structure chart you need to be able to distinguish
between two kinds of processes (Hamlet and Maybee, 2001): those that
carry out data synthesis and those that carry out data refinement:
 • A process said to carry out data synthesis transforms incoming data into
data that did not previously exist.
 • A process said to carry out data refinement selects or merges incoming or
outgoing data.
 Based on this distinction we refer to the part of a DFD that carries out the
main processes of data synthesis as the central transform of the DFD.
 In Figure 6.3 the boundaries of the central transform within the DFD are
indicated by the oval around processes 2 and 3.
  A structure chart (see Figure 6.4) can then be represented as follows
(Hamlet and Maybee, 2001): in the first instance the central transform of
the level-1 DFD is identified. The overall level-0 process is then represented
as a box. Underneath each incoming refinement transform, the central
transform, and each outgoing refinement transform is represented as a
branching box (no incoming refinement transforms exist in this example).
 Although the refinement transform boxes are labelled with their transform
names, a new name is created for the central transform (in this case
‘Determination of Payments and Deductions’). The central transform is

branched out further into its components. Labelled arrows are introduced to
indicate the data flow between boxes (modules). The data that flows
between the modules at the highest level of the hierarchy (below the
control module) flows via the top box (the control module).

 Figure 6.4 shows the structure chart for the level-1 DFD. In a next step
further structure charts need to be created for any lower level DFDs
following the same approach using the previous level DFD as a starting
point. In this case ‘Calculate Deduction and Net Pay’, for example, should be
branched out further. The completed structure chart, together with the data
dictionary, provides a detailed and structured overview of the system’s
modules and the data flows between them.

 Interface design
o Interface design can be divided into internal, external and human computer
interface design (Pressman, 2005).
o Internal interface design is concerned with the design of interfaces in between
modules within the system. For example, the design of a system may be made up of
 a data entry module, a data storage module and a data reporting module. The
interconnections between these three modules have to be identified clearly. What
happens, for example, when the data entry module receives some data that the
storage module determines to be invalid? Which module is responsible for informing
the system user of the error and obtaining new data?
o External interface design is concerned with the design of interfaces to other external
entities. A software application may require the input of some sensory data which
requires interfacing with an external entity (i.e. a data sensor). Note that external
interface design is also used in the same way within the object-oriented paradigm.
o Finally, human–computer interface design is concerned with providing good
usability for the system user. Although aspects of usability include factors of costs
and efficiency, human factor issues have gained increasing consideration in the
design of the human-computer interface.
o User interface design should be user-centred. The interface should ensure that the
users can interact with the system on their terms. It should be logical and consistent
and should include facilities to help users with the system and to recover from any
mistakes they may make. Graphical interfaces, where the user has multiple
windows, menus, iconic object representations and a pointing device, have the
major advantage that they are easy to use, since they are intuitive due to their self-
evidence.
o A detailed explanation of their use should not be required and consistency can easily
be maintained by using the same representation for the same actions in different
applications, like the use of icons in the windows environment.
o Many software development tools (e.g. programming languages, spreadsheets and
databases) provide user interface development tools. These allow you to design
your own user interface conforming to certain standards within the software. For
example, you may be able to define overlapping windows in various sizes, pull down
menus, dialogue boxes and pointing device support.
 Component-level design
o Once data, architectural and interface design have been completed, more detailed
attention is paid to the individual components of the system within the component-
level design (also referred to as procedural design).
o This means that the data structures identified in the data model, the interface
identified during interface design, and the individual modules that have been
determined within the architectural design, now have to be described in more
detail. There are a number of ways in which this can be done. It is possible to use
pseudocode. Within pseudocode simple natural language (e.g. English) is combined
with more structured programming constructs in order to describe an algorithm.
o Pseudocode itself cannot be compiled, but it can easily be translated further into the
source code of a real programming language.
o Alternatively it is possible to use a graphical representation. Flowcharts are a
popular and long-established modelling technique that are particularly useful for the
representation of the algorithms within a module. A flow chart uses graphical
notations for the representation of the programming structures with which you are
familiar from 138 Information and communication technologies. (i.e. sequence,
repetition, selection). A box is used to represent one or a sequence of processing
steps, a diamond represents a logical condition, and the flow of control is indicated
 by arrows that link boxes and diamonds. Within component-level design,
pseudocode and flowcharts (and other techniques which are not discussed here)
aim to reduce the level of abstraction of the previous design models. The resulting
procedural specification can then easily be translated into program code.

(pressman)

The Design Model

 The design model can be viewed in two different dimensions as illustrated in Figure 8.4. The
process dimension indicates the evolution of the design model as design tasks are executed
as part of the software process. The abstraction dimension represents the level of detail as
each element of the analysis model is transformed into a design equivalent and then refined
iteratively.
 Referring to Figure 8.4, the dashed line indicates the boundary between the analysis and
design models. In some cases, a clear distinction between the analysis and design models is
possible. In other cases, the analysis model slowly blends into the design and a clear
distinction is less obvious.
 The elements of the design model use many of the same UML diagrams that were used in
the analysis model. The difference is that these diagrams are refined and elaborated as part
of design; more implementation-specific detail is provided, and architectural structure and
 style, components that reside within the architecture, and interfaces between the
components and with the outside world are all emphasized.
 You should note, however, that model elements indicated along the horizontal axis are not
always developed in a sequential fashion. In most cases preliminary architectural design sets
the stage and is followed by interface design and component-level design, which often occur
in parallel. The deployment model is usually delayed until the design has been fully
developed. You can apply design patterns (Chapter 12) at any point during design. These
patterns enable you to apply design knowledge to domain-specific problems that have been
encountered and solved by others.

Data Design elements

 Like other software engineering activities, data design (sometimes referred to as data
architecting) creates a model of data and/or information that is represented at a high level
of abstraction (the customer/user’s view of data). This data model is then refined into
progressively more implementation-specific representations that can be processed by the
computer-based system. In many software applications, the architecture of the data will
have a profound influence on the architecture of the software that must process it.
 The structure of data has always been an important part of software design. At the program
component level, the design of data structures and the associated algorithms required to
manipulate them is essential to the creation of high-quality applications. At the application
level, the translation of a data model (derived as part of requirements engineering) into a
database is pivotal to achieving the business objectives of a system. At the business level,
the collection of information stored in disparate databases and reorganized into a “data
warehouse” enables data mining or knowledge discovery that can have an impact on the
success of the business itself. In every case, data design plays an important role.

Architectural Design elements

 The architectural design for software is the equivalent to the floor plan of a house. The floor
plan depicts the overall layout of the rooms; their size, shape, and relationship to one
another; and the doors and windows that allow movement into and out of the rooms. The
floor plan gives us an overall view of the house. Architectural design elements give us an
overall view of the software.
 The architectural model [Sha96] is derived from three sources:
1. information about the application domain for the software to be built;
2. specific requirements model elements such as data flow diagrams or analysis
classes, their relationships and collaborations for the problem at hand; and
3. the availability of architectural styles (Chapter 9) and patterns (Chapter 12).
 The architectural design element is usually depicted as a set of interconnected subsystems,
often derived from analysis packages within the requirements model.
 Each subsystem may have it’s own architecture (e.g., a graphical user interface might be
structured according to a pre-existing architectural style for user interfaces). Techniques for
deriving specific elements of the architectural model are presented in Chapter 9.

Interface Design Elements

 The interface design for software is analogous to a set of detailed drawings (and
specifications) for the doors, windows, and external utilities of a house. These drawings
depict the size and shape of doors and windows, the manner in which they operate, the way
 in which utility connections (e.g., water, electrical, gas, telephone) come into the house and
are distributed among the rooms depicted in the floor plan.
 They tell us where the doorbell is located, whether an intercom is to be used to announce a
visitor’s presence, and how a security system is to be installed. In essence, the detailed
drawings (and specifications) for the doors, windows, and external utilities tell us how things
and information flow into and out of the house and within the rooms that are part of the
floor plan. The interface design elements for software depict information flows into and out
of the system and how it is communicated among the components defined as part of the
architecture.
 There are three important elements of interface design:
o the user interface (UI);
o external interfaces to other systems, devices, networks, or other producers or
consumers of information; and
o internal interfaces between various design components. These interface design
elements allow the software to communicate externally and enable internal
communication and collaboration among the components that populate the
software architecture.
 UI design (increasingly called usability design) is a major software engineering action and is
considered in detail in Chapter 11. Usability design incorporates aesthetic elements (e.g.,
layout, color, graphics, interaction mechanisms), ergonomic elements (e.g., information
layout and placement, metaphors, UI navigation), and technical elements (e.g., UI patterns,
reusable components). In general, the UI is a unique subsystem within the overall
application architecture
 The design of internal interfaces is closely aligned with component-level design (Chapter 10).
Design realizations of analysis classes represent all operations and the messaging schemes
required to enable communication and collaboration between operations in various classes.
Each message must be designed to accommodate the requisite information transfer and the
specific functional requirements of the operation that has been requested. If the classic
input-process-output approach to design is chosen, the interface of each software
component is designed based on data flow representations and the functionality described
in a processing narrative.

Component-Level Design elements

 The component-level design for software is the equivalent to a set of detailed drawings (and
specifications) for each room in a house. These drawings depict wiring and plumbing within
each room, the location of electrical receptacles and wall switches, faucets, sinks, showers,
tubs, drains, cabinets, and closets. They also describe the flooring to be used, the moldings
to be applied, and every other detail associated with a room.
 The component-level design for software fully describes the internal detail of each software
component. To accomplish this, the component-level design defines data structures for all
local data objects and algorithmic detail for all processing that occurs within a component
and an interface that allows access to all component operations (behaviors).
 The design details of a component can be modeled at many different levels of abstraction. A
UML activity diagram can be used to represent processing logic.
 Detailed procedural flow for a component can be represented using either pseudocode (a
programming language-like representation described in Chapter 10) or some other
diagrammatic form (e.g., flowchart or box diagram). Algorithmic structure follows the rules
established for structured programming (i.e., a set of constrained procedural constructs).
Data structures, selected based on the nature of the data objects to be processed, are
usually modeled using pseudocode or the programming language to be used for
implementation.