CS8494 – SOFTWARE ENGINEERING

UNIT – II SOFTWARE REQUIREMENTS

Software Requirements: Functional and Non-Functional, User requirements, System requirements,
Software Requirements Document – Requirement Engineering Process: Feasibility Studies,
Requirements elicitation and analysis, requirements validation, requirements management-Classical
analysis: Structured system Analysis, Petri Nets- Data Dictionary.

Requirement
 A requirement is a feature of the system or a description of something the system is capable
of doing in order to fulfill the system’s purpose.
 It may range from a high-level abstract statement of a service or of a system constraint to a
detailed mathematical functional specification.
 The requirements for a system are the descriptions of what the system should do—the
services that it provides and the constraints on its operation. These requirements reflect the
needs of customers for a system that serves a certain purpose such as controlling a device,
placing an order, or finding information. The process of finding out, analyzing, documenting
and checking these services and constraints is called requirements engineering (RE).
Requirement Engineering
 The process of finding out, analyzing, documenting and checking these services and
constraints is called requirements engineering.
 Requirement engineering provides a description of what the system will do without knowing
how to do it.
Types of Requirements

 User requirements
 Statements in natural language plus diagrams of the services that the system is
expected to provide and its operational constraints.
1
  User requirements are statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users and the constraints
under which it must operate.
 Written for customers
 System requirements
 System requirements are more detailed descriptions of the software system’s
functions, services, and operational constraints. The system requirements document
(sometimes called a functional specification) should define exactly what is to be
implemented. It may be part of the contract between the system buyer and the
software developers.
 A structured document setting out detailed descriptions of the system services.
 Written as a contract between client and contractor
 Software specification
 A detailed software description which can serve as a basis for a design or
implementation.
 Written for developers.

Functional and non-Functional Requirements

Software system requirements are often classified as follows:
 Functional Requirements
 Non-Functional Requirements
 Domain Requirements

1. Functional Requirements
 These are statements of services the system should

 provide, how the system should react to particular inputs, and how the system should behave
in particular situations. In some cases, the functional requirements may also explicitly state
what the system should not do.

 A functional requirement defines a function of a system is expected to provide.

 A function is described as a set of inputs, the behavior, and outputs

2
  Statements of services the system should provide how the system should react to particular
inputs and how the system should behave in particular situations.
 It depend on the type of software, expected users and the type of system where the software
is used
 Functional user requirements may be high-level statements of what the system should do but
functional system requirements should describe the system services in detail
E.g. Library system
 The user shall be able to search either all of the initial set of databases or select a subset
from it.
 The system shall provide appropriate viewers for the user to read documents in the
document store.
 Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able
to copy to the account’s permanent storage area.
Problems:
 Requirements imprecision:
 Problems arise when requirements are not precisely stated.
 Ambiguous requirements may be interpreted in different ways by developers and
users.
 Requirements completeness and consistency:
In principle requirements should be both complete and consistent
 Complete:-They should include descriptions of all facilities required.
 Consistent:-There should be no conflicts or contradictions in the descriptions of the
system facilities.
In practice, it is impossible to produce a complete and consistent requirements document.

2. Non-Functional Requirements
 These are constraints on the services or functions offered by the system. They include
timing constraints, constraints on the development process, and constraints imposed by
standards. Non-functional requirements often apply to the system as a whole, rather than
individual system features or services.
 As the name suggests that those requirements are not directly concerned with specific
functions delivered by the system.

3
 It define system properties and constraints such as reliability, response time and storage
occupancy. Constraints are I/O device capability, system representations, etc.
 Many non-functional requirements relate to the system as a whole rather than to individual
system features. While failure to meet an individual functional requirement may degrade the
system.
 Process requirements may also be specified mandating a particular CASE system,
programming language or development method.
 Non-functional requirements may be more critical than functional requirements. If these do
not meet the complete system, the system is useless.
Non-functional
requir ements

Product Or ganizational External

requir ements requir ements requirements

Ef ficiency Reliability Portability Interoperability Ethical

requir ements requir ements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requir ements requirements requirements

Performance Space Privacy Safety

requirements requir ements requirements requirements

 Product requirements:
 Requirements which specify that the delivered product must behave in a particular
way e.g. execution speed, reliability, etc.
 Organisational requirements:
 Requirements which are a consequence of organisational policies and procedures
e.g. process standards used, implementation requirements, etc.
 External requirements:
 Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.

4
The implementation of these requirements may be diffused throughout the system. There are
two reasons for this
1. Non-functional requirements may affect the overall architecture of a system
rather than the individual components. For example, to ensure that performance
requirements are met, you may have to organize the system to minimize communications between
components.
2. A single non-functional requirement, such as a security requirement, may generate a number of
related functional requirements that define new system services that are required. In addition, it
may also generate requirements that restrict existing requirements.
Metrics for specifying non-functional requirements

5
3. Domain Requirements
 Domain requirements are derived from the application domain and describe system
characteristics and features that reflect the domain.
 It may be new functional requirements, constraints on existing requirements or define
specific computations.
 Domain requirements are important because they often reflect fundamentals of the
application domain.
 If domain requirements are not satisfied, the system may be unworkable.
E.g. Library system domain requirements
 There shall be a standard user interface to all databases which shall be based on the Z39.50
standard.
 Because of copyright restrictions, some documents must be deleted immediately on arrival.
Depending on the user’s requirements, these documents will either be printed locally on the
system server for manually forwarding to the user or routed to a network printer.
Problems:
 Understandability
 Requirements are expressed in the language of the application domain (For e.g. in
mathematical form)
 This is often not understood by software engineers developing the system.
 Implicitness
 Domain specialists understand the area so well that they do not think of making the
domain requirements explicit.

User Requirements
 The user requirements of a system should describe the functional and non-functional
requirements so that they are understandable by system users who don’t have detailed
technical knowledge.
 User requirements are defined using natural language, tables and diagrams.
Problems with Natural Language:
Various problems will arise when requirements are written in natural language:
 Lack of clarity:

6
  It is sometimes difficult to use language in a precise and unambiguous way without
making the document wordy and difficult to read.
 Requirements confusion:
 Functional, non-functional requirements, system goals and design information may
not be clearly distinguished.
 Requirements amalgamation:
 Several different requirements may be expressed together as a single document.
E.g. Library System
 LIBSYS shall provide a financial accounting system that maintains records of all payments
made by users of the system. System managers may configure this system so that regular
users may receive discounted rates.
Guidelines for writing requirements:
To minimise misunderstandings when writing user requirements, the following guidelines
should be followed.
 Invent a standard format and ensure that all requirement definitions adhere to that format.
 Use language in a consistent way. Use shall for mandatory requirements, should for
desirable requirements.
 Use text highlighting to identify key parts of the requirement.
 Avoid the use of computer jargons.

System Requirements
 System requirements are more detailed description of user requirements.
 They may serve as the basis for a contract for the implementation of the system and should
therefore be a complete and consistent specification of the whole system.
 They are used by the software engineers as the starting point for the system design.
 System requirements specification may include different models of the system such as an
object model or data model.
 Requirements should state what the system should do and not how it should be
implemented.

But requirements and design are inseparable, because of following reasons:

 A system architecture may be designed to structure the requirements

7
  The system may inter-operate with other systems that generate design requirements
 The use of a specific design may be a domain requirement.
 Natural language (NL) is often used to write system requirements specifications.
Problems with NL specification
 Ambiguity
 The readers and writers of the requirement must interpret the same words in the
same way. This leads to misunderstandings because of the ambiguity of natural
language.
 Over-flexibility
 The same thing may be said in a number of different ways in the specification.
 Lack of modularisation
 It may be difficult to find all related requirements. If you needs any change, you may
have to look at every requirements rather than group of requirements.
Structured language specifications
 Structured language is a restricted form of natural language for writing system requirements
 This removes some of the problems resulting from ambiguity and flexibility and imposes a
degree of uniformity on a specification.
 Structured language notations may limit the terminology used and may use templates to
specify system requirements.
 Often used a forms-based approach.
 To use form based approach, we must use one or more standard forms or templates to
express the requirements.
When standard form is used for specifying functional requirements, the following information
should be included:
 A description of the function or entity being specified.
 A description of its input and where these come from
 A description of its outputs and where these go to
 An indication of what other entities are used.

Requirements specification using PDL

8
  Requirements may be defined operationally using a language like a programming
description language (PDL) but with more flexibility of expression.
 The advantage of PDL is that it may be checked syntactically and semantically by software
tools.
PDL is most appropriate in two situations
 Where an operation is specified as a sequence of actions and the order is important.
 When hardware and software interfaces have to be specified.
Disadvantages
 The PDL may not be sufficiently expressive to describe the system functionality.
 The notation can be understood only the people have programming language.
 The specification will be taken as a design specification rather than a model to help the user
understand the system.
Interface Specification
 Most software systems must operate with other systems.
 If the new system and existing system work together, the interface of the existing system
must be precisely specified.
Three types of interface may have to be defined
 Procedural interfaces
 In this interface where the existing sub-systems offer a range of services which are
accessed by calling interface procedures.
 Data structures that are exchanged from one sub system to another.
 Data representations
 Representation of data which have been established for an existing system.
 Generally, Formal notations are an effective technique for interface specification.
Software requirements document
 The software requirements document (sometimes called the software requirements
specification or SRS) is an official statement of what the system developers should
implement.
 It should include both the user requirements for a system and a detailed specification of the
system requirements. Sometimes, the user and system requirements are integrated into a
single description. In other cases, the user requirements are defined in an introduction to the

9
 system requirements specification. If there are a large number of requirements, the detailed
system requirements may be presented in a separate document.
 Requirements documents are essential when an outside contractor is developing the software
system.
 However, agile development methods argue that requirements change so rapidly that a
requirements document is out of date as soon as it is written, so the effort is largely wasted.
Rather than a formal document, approaches such as Extreme Programming (Beck, 1999)
collect user requirements incrementally and write these on cards as user stories. The user
then prioritizes requirements for implementation in the next increment of the system.

Users of a Engineers requirements document

10
The Structure of a requirements document

Requirements Engineering Processes

11
  Requirement engineering is a process that involves all of the activities required to create and
maintain a system requirement document.

A spiral view of the requirements engineering process

 The activities are organized as an iterative process around a spiral, with the output being a
system requirements document.
 Some people consider requirements engineering to be the process of applying a structured
analysis method, such as object-oriented analysis (Larman, 2002). This involves analyzing
the system and developing a set of graphical system models, such as use case models, which
then serve as a system specification.
 The set of models describes the behavior of the system and is annotated with additional
information describing, for example, the system’s required performance or reliability.

12
  Although structured methods have a role to play in the requirements engineering process,
there is much more to requirements engineering than is covered by these methods.
Requirements elicitation, in particular, is a human-centered activity and people dislike the
constraints imposed on it by rigid system models.
 In virtually all systems, requirements change. The people involved develop a better
understanding of what they want the software to do; the organization buying the system
changes; modifications are made to the system’s hardware, software, and organizational
environment. The process of managing these changing requirements is called
requirements management.
 Requirement engineering process activities are as follows
 Feasibility Study
 Requirements elicitation and analysis
 Requirements specification and their documentation
 Validation of requirements

Feasibility Studies
 The Requirement engineering process should start with feasibility study.
 Feasibility study is a study made to decide whether or not the proposed system is
worthwhile.
 The input to the feasibility study is the outline description of the system and how it will be
used within the organization.
 The result of feasibility study is the report which reports whether or not to implement the
system.
 Feasibility study that checks that

13
  Does the system contribute to organisational objectives?
 If the system can be engineered using current technology and within budget?
 Can the system be integrated with other systems that are already used?
 Feasibility study involves information assessment, information collection and report writing.
 Information assessment identifies the information which is required to answer the three
questions set above.
 Once the information has been identified, you should question information sources to
discover the answer to these questions.
Some examples of possible Questions for people in the organisation are:
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
 Feasibility study should be done with the help of project managers who is going to handle
the project, software engineers, technical experts, end-users of the system etc.,
 Feasibility study should be completed within two or three weeks.
 When the information is available, Feasibility study report is prepared.
Requirements Elicitation and Analysis
 After Feasibility studies, the next stage of requirement engineering process is requirement
elicitation and analysis.
 In this activity, technical staff working with customers to find out about the application
domain, the services that the system should provide and the system’s operational
constraints, hardware constraints and so on.
Elicitation and analysis is a difficult process for a number of reasons:
 Stakeholders don’t know what they really want in the computer system.
 Stakeholders express their requirements in their own terms.
 Different stakeholders may have different requirements and they may express in different
way.
 Organisational and political factors may influence the system requirements

14
  The requirements change during the analysis process. New stakeholders may emerge from
new stakeholders who were not originally consulted and the business environment change.
Various process activities are discussed in the following diagram.

 Domain Understanding – Analysts must develop their understanding of the application

domain.
 Requirements Collection - Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
 Requirements classification - Groups related requirements and organises them into
coherent clusters.
 Conflict Resolution – If multiple stakeholders involved, requirements will conflict. In this
activity those conflicts are resolved.
 Prioritisation – Interaction with stakeholders to discover the most important requirements.
 Requirements Checking – Requirements are checked to discover whether they are
complete and consistent.
Interviewing
 This is an effective way of requirements gathering.
 In formal or informal interviewing, the requirement engineering team puts questions to
stakeholders about the system that they use and the system to be developed.
Types
 Closed interviews:- where a pre-defined set of questions are answered by stakeholder.

15
  Open interviews:- where there is no pre-defined agenda and a range of issues are explored
and discussed with stakeholders.
Effective Interview
 The interview should be conducted with open minded approach. The requirement engineers
should listen to the stakeholders with patience. Similarly some stakeholders are expecting
some unrealistic things about the system they should be ready to change their mind and
ideas about the system.
 Interviewee should start the discussion by asking questions and requirements should be
gathered together.
Use cases
 Use case is a scenario for understanding user requirements.
 Use-cases are a scenario based technique in the UML which identify the actors in an
interaction and which describe the interaction itself.
 A set of use cases should describe all possible interactions with the system.

E.g. Use case Diagram for Library management System

Article search

Lib rary Article p rin tin g

User

User ad m in istratio n Lib rary

Staff

Su p p lier Catalo g u e serv ices

Quality Function Deployment (QFD)

 Quality Function Deployment is a quality management technique which translates the
customer needs and wants into technical requirements.

16
 There are three types of requirements in QFD are:
 Normal Requirements
 Requirements as per goals and objectives of the system.
 Eg: Handling mouse and keyboard events for any GUI based system
 Expected Requirements
 These type of requirements in which the system must be having even if the
customer did not mention them.
 E.g. A software package for presentation (MS-PPT) must have option of ‘new
slide insert’.
 Exciting Requirements
 When certain requirements are satisfied by the software beyond the customer
expectations.
 E.g. spell check facility in Ms-word.
Ethnography
 Ethnography is an observational technique that can be used to understand social and
organizational factors.
 Ethnography and prototyping for requirements analysis

Requirements Validation:
 Requirements validation concerned with demonstrating that the requirements define the
system that the customer really wants.
 Requirements validation is important because errors in a requirement document can lead to
extensive rework costs when after the system is in service.
During Requirements validation process, different types of checks should be carried out.
 Validity - Does the system provide the functions which best support the customer’s
needs?

17
  Consistency - Are there any requirements conflicts?
 Completeness - Are all functions required by the customer included?
 Realism - Can the requirements be implemented given available budget and technology
 Verifiability - Can the requirements be checked?
Requirements Validation Techniques:
 Requirements reviews- The requirements are analysed systematically by a team of
reviewers.
 Prototyping-Using an executable model of the system is demonstrated to the end user
or customers.
 Test-case generation-Developing tests for requirements to check testability.
Requirement Reviews:
 Regular reviews should be held while the requirements definition is being formulated.
 Both client and contractor staff should be involved in reviews.
 Reviews may be formal (with completed documents) or informal. Good communications
between developers, customers and users can resolve problems at an early stage.
Reviewers may also check for:
 Verifiability. Is the requirement as stated realistically testable?
 Comprehensibility. Is the requirement properly understood by the end-users of the
system?
 Traceability. Is the origin of the requirement clearly stated?
 Adaptability. Can the requirement be changed without a large impact on other
requirements? Or Is the requirement adaptable?
Requirements Management:
 Requirements management is the process of managing changing requirements during the
requirements engineering process and system development.
 Requirements are inevitably incomplete and inconsistent
Requirements Management Planning:
 During the requirements engineering process, you have to plan:
 Requirements identification - How requirements are individually identified.
 A change management process - The process followed when analysing a requirements
change.

18
  Traceability policies - The amount of information about requirements relationships that
is maintained.
 CASE tool support - The tool support required to help manage requirements change.
Traceability:
 Traceability is concerned with the relationships between requirements, their sources and the
system design
 Source traceability
 Links from requirements to stakeholders who proposed these requirements;
 Requirements traceability
 Links between dependent requirements;
 Design traceability
 Links from the requirements to the design.
There are three principal stages to a change management process:
1.Problem analysis and change specification The process starts with an identified requirements
problem or, sometimes, with a specific change proposal. During this stage, the problem or the
change proposal is analyzed to check that it is valid. This analysis is fed back to the change
requestor who may respond with a more specific requirements change proposal, or decide to
withdraw the request.
2. Change analysis and costing The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements. The cost of making the change is
estimated both in terms of modifications to the requirements document and, if appropriate, to the
system design and implementation. Once this analysis is completed, a decision is made whether or
not to proceed with the requirements change.
3. Change implementation The requirements document and, where necessary, the system design and
implementation, are modified. You should organize the requirements document so that you can
make changes to it without extensive rewriting or reorganization. As with programs, changeability
in documents is achieved by minimizing external references and making the document sections as
modular as possible. Thus, individual sections can be changed and replaced without affecting other
parts of the document.
Structured Systems Analysis
The use of graphics to specify software was an important technique of the 1970s. Three
techniques using graphics became particularly popular: those of DeMarco [1978], Gane and Sarsen

19
[1979], and Yourdon and Constantine [1979]. All three techniques are equally good and essentially
equivalent. Gane and Sarsen’s approach is presented here because their notation, currently,
Probably is the most widely used in the industry.
The symbols of Gane and Sarsen’s structured systems analysis.
The DFD uses the four basic symbols

Gane and Sarsen [1979] use structured systems analysis , a nine-step technique, to analyze the
client’s needs. An important point is that stepwise refi nement is used in many of those nine steps;
this will be indicated as the technique is demonstrated. Having determined Sally’s requirements, the
fi rst step in the structured systems analysis is to determine the logical data fl ow , as opposed to the
physical data fl ow (that is, what happens, as opposed to how it happens). This is done by drawing a
data flow diagram (DFD).

Step 1. Draw the DFD

First refinement
Infinite number of possible interpretations

20
 Second refinement
pending orders scanned daily

Portion of third refinement

21
Final DFD -Larger, But easily understood by client
Larger DFDs-Hierarchy
-Box becomes DFD at lower level
Frequent problem
Process P at level L, expanded at level L+1
Correct place for sources and destinations of data for process P is level L+1
Clients cannot understand DFD—sources and destinations of data for P are “missing”
Solution
Draw “correct” DFD, modify by moving sources and destinations of data one or more levels up
Step 2. Decide What Parts to Computerize
 Depends on how much client is prepared to spend
 Large volumes, tight controls-Batch
 Small volumes, in-house microcomputer -Online
 Cost/benefit analysis
Step 3. Refine Data Flows
 Data items for each data flow
 Refine each flow stepwise
 Refine further
 Need a data dictionary
Sample data dictionaries entries

22
Step 4. Refine Logic of Processes:
Have process give educational discount
– Sally must explain discount for educational institutions
– 10% on up to 4 packages, 15% on 5 or more
Translate into decision tree

Can also use decision tables

– CASE tools for automatic translation
Step 5. Refine Data Stores
Define exact contents and representation (format)
– COBOL: specify to pic level

23
 – Ada: specify digits or delta
Specify where immediate access is required
– Data immediate access diagram (DIAD)

Step 6. Define Physical Resources

For each file, specify
– File name
– Organization (sequential, indexed, etc.)
– Storage medium
– Blocking factor
– Records (to field level)
Step 7. Determine Input/Output Specs
 Specify input forms, input screens, printed output
 The input forms must be specifi ed, at least with respect to components, if not
detailed layout. Input screens must similarly be determined. The printed output also
must be specifi ed, where possible in detail, otherwise just estimated length.
Step 8. Perform Sizing
Numerical data for Step 9 to determine hardware requirements
– Volume of input (daily or hourly)

24
 – Size, frequency, deadline of each printed report
– Size, number of records passing between CPU and mass storage
– Size of each file
Step 9. Hardware Requirements
DASD requirements
Mass storage for back-up
Input needs
Output devices
Is existing hardware adequate?
If not, recommend buy/lease
Petri Nets
A major difficulty with specifying concurrent systems is coping with timing. This
difficulty can manifest itself in many different ways, such as synchronization problems, race
conditions, and deadlock [Silberschatz, Galvin, and Gagne, 2002].
Although timing problems can arise as a consequence of a poor design or a faulty implementation,
such designs and implementations often are the consequence of poor specifications. If specifications
are not properly drawn up, there is a very real risk that the corresponding design and
implementation will be inadequate. One powerful technique for specifying systems with potential
timing problems is Petri nets. A further advantage of this technique is that it can be used for the
design as well.
A major difficulty with specifying real-time systems is timing
– Synchronization problems
– Race conditions
– Deadlock
Often a consequence of poor specifications
Petri nets
– Powerful technique for specifying systems with potential timing problems
A Petri net consists of four parts:
– Set of places P
– Set of transitions T
– Input function I
– Output function O

25
Set of places P is {p1, p2, p3, p4}
Set of transitions T is {t1, t2}
Input functions:
I(t1) = {p2, p4}
I(t2) = {p2}
Output functions:
O(t1) = {p1}
O(t2) = {p3, p3}

More formally, a Petri net is a 4-tuple C = (P, T, I, O)

P = {p1, p2,…,pn} is a finite set of places, n ≥ 0
T = {t1, t2,…,tm} is a finite set of transitions, m ≥ 0, with P and T disjoint
I : T ® P∞ is input function, mapping from transitions to bags of places
O : T ® P∞ is output function, mapping from transitions to bags of places
(A bag is a generalization of sets which allows for multiple instances of element in bag, as
in example above)
Marking of a Petri net is an assignment of tokens to that Petri net

26
Four tokens, one in p1, two in p2, none in p3, and one in p4
– Represented by vector (1,2,0,1)
Transition is enabled if each of its input places has as many tokens in it as there arcs from
the place to that transition
Transition t1 is enabled (ready to fire)
– If t1 fires, one token is removed from p2 and one from p4, and one new token is
placed in p1
Important: Number of tokens is not conserved
Transition t2 is also enabled
Petri nets are indeterminate
– Suppose t1 fires

Resulting marking is (2,1,0,0)

Now only t2 is enabled -It fires

27
Marking is now (2,0,2,0)
More formally, a marking M of a Petri net C = (P, T, I, O) is a function from the set of places
P to the non-negative integers N :M :
P ->N
A marked Petri net is then 5-tuple (P, T, I, O, M )
Data Dictionary
Definition
Data dictionary can be defined as an organized collection of all the data elements of the
system with precise and rigorous definitions so that user and system analyst will have a common
understanding of inputs, outputs, components of stores and intermediate calculations.
 The data models are less in detail hence there is a need for Data Dictionary.
 Data Dictionaries are lists of all of the names used in the system model.
 Descriptions of the entities, relationships and attributes are also included in the data
dictionary.
 Typically, the data dictionaries are implemented as a part of structured analysis and design
tool.
The data dictionary stores the following information:
 Name-Primary name is specified.
 Alias-Another name for primary name.
 Where we used/how we used-specifies input or output.
Notations used in Data Dictionary:
 = Composed of

28
  + Sequence
 {|} Or
 {}^n Repetitions- n repetitions of optional data
 *…* Comments
Example:
Consider the Reservation System. The data item “Passenger” can be entered in the data
dictionary as:

Name: Passenger
Alias: none
Where used/How used: Passenger’s Query(Input), ticket(Output)
Description:
Passenger = Passenger_name+Passenger_address
Passenger_name = Passenger_firstname+Passenger_lastname+Passenger_middlename
Passenger_address = Local address+community_adrress+zip code
Local_adrress = house_number+street_name
community_adrress = city_name+[state_name|province_name]

Advantages:
 Data Dictionary support name management and avoid duplication
 It is a store of organisational knowledge linking analysis, design and implementation.

29