Chapter 05: Analysis Techniques

1
Chapter 05 Analysis Techniques

• We will review and apply the techniques that can
  be used to document the software requirements.
• 5.1 Vision
• Can be broken up into
• Introduction
• Business Case
• Stakeholders Descriptions and Goals
• Software Overview
• Summary of Software Features
• It needs to be kept short
• Example See Separate Vision Document
• A very short introduction.
• Making the business case in important (as is
  evaluating alternatives e.g. other similar
  applications).
• Identifying the end users and researching their
  abilities and needs is important.
• Note the use of a basic, but very useful, System
  Context Diagram

2

• Note the very terse list of features.
• 5.2 Functional Model
• Can be broken up into
• GUI Prototype Screenshots
• Brief Use Cases
• Use Case diagrams
• Some Detailed Use Cases
• Some System Sequence Diagrams
• Prototyping Techniques and GUI design are seen in
  other chapters
• 5.2.1 Brief Use Cases
• A use case describes sequences of actions a
  system performs that yields an observable result
  of value to a particular actor. I.e. A use case
  is a narrative document that describes the
  sequence of events of an actor (an external
  agent) using a system to complete a process.

3

• Example of a brief use case for a computerised
  shop Buying items in a shop
• Use Case Buy Items
• Actors Customer, Cashier
• Description A Customer arrives at a checkout
  with items to purchase. The Cashier records the
  items to be purchased and collects payment. On
  completion, the Customer leaves with the items.
• A brief use case must remain short but yet
  encapsulate the entire process from an actor
  point of view.
• An actor in an entity external to the system
• Kinds of actors include
• roles that people play
• computer systems
• electrical or mechanical devices
• A use case is a relatively large end-to-end
  process description that typically includes many
  steps or transactions it is not normally an
  individual step or activity in a process.
• Initially all actors and all the most
  important/critical use cases need to discovered
  and documented in a brief format.

4

• Use Cases and GUI prototyping should occur in
  parallel and feed off each other.
• 5.2.2 Use Case Diagram
• The use cases can be summarised very simply using
  a use case diagram (UML)

5

• 5.2.3 Detailed Use Cases
• Complex, important use cases may need to be
  detailed further
• We add a typical course of event section to the
  use case it describe the happy path of events
  of the process
• We can also add an alternatives section that list
  the main options
• Example See Use Case Separate Document
• Detailing a use case can take time it is
  necessary for the most important/critical
  processes of the future system
• 5.2.4 System Sequence Diagrams
• A system sequence diagram shows the sequence of
  input and output events for the entire system or
  some use case.
• It brings us a step closer to design.
• They can be obtained by reading very carefully
  the use cases (and correct them if necessary)

6

• Example of System Sequence Diagram (UML) for the
  Buy Items Use Case

• You must read the Buy Items Use Case in its
  detailed format (see separate document) to
  understand where the SSD above comes from.

7

• Sequence diagrams can become very (too) complex
  try to keep them simple create more than one
  for a given use case if necessary.

• In the UML, we can use the loop, alt, opt (and
  others) operators to indicate iterations,
  alternatives, or optional sequences.

8

• 5.2.5 Tutorial
• A Library system See Separate Document
• 5.2.6 Conclusion on Functional Model
• It takes time to document a good, verified,
  agreed, functional model
• It must the composed of
• GUI Prototype Screenshots
• Brief Use Cases
• Use Case diagrams
• Some Detailed Use Cases
• Some System Sequence Diagrams
• 5.3 Data Model
• It can be broken into
• Basic Data Descriptions
• Entity Relationship Diagram
• 5.3.1 Basic Data Description
• Some of the data manipulated by software are
  un-related to each other and are quite simple.
  For example an address, a user name, a country
  name etc.
• For this kind of data it is important to identify
  all the inputs and outputs that the system will
  manipulate (as well as their frequency).

9

• The format of the data needs to be detailed very
  briefly at this stage.
• Simple English description is usually sufficient,
  E.g.
• Address composed of Address1 field (100 chars
  max), Address2 field (optional, 100 chars max),
  Postcode (optional, ??), Town/City (50 chars
  max), Region/County (drop down box?), Country
  (drop down box)
• User Name between 5 to 15 alphanumerical chars
• Country Name Drop down list (from International
  Standard Organisation)
• Some research may be necessary to discover what
  information the system need to track E.g. a
  payroll system
• employment contract (official position
  description, grade (??), hours worked, automatic
  deductions, tax rate etc.
• All of these are very important to establish
  during the analysis of a payroll system project
  as they maybe more complex than initially thought
  

10

• But sometimes more complex data descriptions are
  necessary using a specific notation E.g.
• Phone number Local_ExtensionOutside_Number
• Local_Extension 701 750
• Outside_Number 9Local_NumberInternational_Num
  ber
• Local_Number PrefixDigit
• Prefix Digit
• International_Number 00Country_CodeNational_Nu
  mber
• This is usually straightforward to do but
  beware to research the area properly (E.g. for
  future localisation of the software, if the area
  under consideration is fuzzy)
• A data Glossary can be used to describe the data
  entities manipulated by the software it is a
  central repository of terms used in the
  application
• It can also serve as a cross-referencing tool for
  all the terminology used in a project to ensure
  consistency
• CASE tools can be used to record the Glossary

11

• 5.3.2 Entity Relationship Diagrams
• If the data that the software will manipulate has
  strong inter-dependence then entity-relationship
  diagrams are necessary
• This is typical of database systems
• Even if the software will not contain a database,
  Entity Relationship Diagrams may be necessary if
  the data has some inter-relationships.
• We may need ERDs for data input, stored,
  transformed and produced within an application.
• An ERD concentrates solely on data (different to
  an Object Oriented approach where operations (aka
  methods) also need to be identified).
• 5.3.2.1 Data Entities, Attributes and
  Relationships
• A data entity is often composed of various
  attributes (i.e. properties).
• For example an insurance system

12

• It is very important to identify all the entities
  that will be manipulated by the software.
• Some attributes may uniquely identify entities
  (e.g. Registration Number for a vehicle) they
  are called keys. Sometimes entities have no
  natural keys (e.g. a person)
• During analysis this does not matter
• During design artificial keys may be created
  (e.g. driver_id, order_number)
• We only want to identify entities and attributes
  that make sense within the application context
  (e.g. height of a person is not relevant for an
  insurance application).

13

• If the entities are related to one another in the
  application context then these relationships need
  to discovered
• It is a sure sign that an Entity Relationship
  Diagram is necessary.
• The attributes will need to detailed eventually
• What is a type for a vehicle?
• What is the format of a registration number?
• Etc.
• This can be done using plain English, or a
  specific notation as seen in section 5.3.1
• 5.3.2.2 Diagram
• We can visualise most of this information using
  an entity relationship diagram
• Many different notations exist and are suitable
  (I use a UML-like notation)
• Just pick one notation and use it consistently
• CASE tools can be used
• E.g. for an insurance system a partial ERD might
  look like

14
Vehicle
Person
Owns
Type Make Model Registration number
Name Address Age
Drives
Is Insured

• We can also record the types of the attributes on
  the diagram (especially is using a CASE tool)
• To add details to ERDs the multiplicity of the
  relationships should also be recorded
• The multiplicity records how many instances of an
  entity are related to another entity within a
  relationship (again various notations exists)
• E.g.

Entity


Zero or more many
15
Entity
1..40

one to forty
Entity
1..

one or more
Entity
5

exactly five

• Example a job agency software

Person
Company
works


Name Address Age
Name Contact Workforce
1

Vacancy
has
Type Duration
has applied


16

• Even on such a very simple example many questions
  need to answered, E.g.
• Can a person work for more than one company?
  (probably)
• Does a vacancy always need a company? (yes)
• Naming the relationship is very important to help
  understanding of the model.
• We should be able to read the relationships both
  ways E.g.
• A person works for some companies
• A company employs some persons
• Your first ERD will probably be wrong
• It needs to be refined, discussed with all
  stakeholders it is primarily a communication
  tool to clarify, elicit, the requirements
• It is also a documentation tool of course
• You need to model all the information that the
  software will need to know about
• 5.3.3 Tutorial
• A Library System See Separate Document

17

• 5.3.4 Conclusion on Data Model
• It can be broken into
• Basic Data Descriptions
• Entity Relationship Diagram
• 5.4 Behavioural Model
• It is mainly made up of
• State Machine Diagrams
• A behavioural model is not always necessary only
  consider using them if you can identify some
  entity for which functions depends on its state
• In general, business applications have few
  state-dependent entities in the
  telecommunication, and device control domains
  however they are everywhere

18

• Transitions between states can have associated
  actions and guards which are conditions which
  must be true for the transition to occur

• We may also have nested states

19

• A state machine diagram represents the states and
  events that cause an entity to change state. It
  can also indicate what actions are taken as a
  consequence of a particular event.
• A state is any observable mode of behaviour
• 5.4.1 Tutorial
• A Library System See Separate Document
• 5.4.2 Conclusion on Behavioural Model
• It is mainly made up of
• State Machine Diagrams
• 5.5 Supplementary Specification
• It can be broken into
• Functionalities across use cases
• Usability
• Reliability
• Performance
• Supportability
• Other Relevant Remarks
• Use cases are best for capturing the functional
  requirements, the supplementary specification is
  there to specify the non-functional requirements
  or the functional requirements that cannot be
  easily described by a use case.

20

• 5.5.1 Functionalities Across Use Cases
• Sometimes some functionalities are not easily
  expressed in a use case or cut across many use
  cases (e.g. many complex systems tend to have
  minimal human interfaces or even other device
  interfaces, but that doesn't mean they don't do a
  lot of work on behalf of someone or something)
• Systems that are primarily algorithmic and
  computational in nature (such as
  satellite-tracking, or telecommunication-switching
  ) achieve their results by implementing a variety
  of scientific and other algorithms. In these
  cases you may choose to use mathematical
  expressions, statistical algorithms, and so on to
  represent the majority of the requirements.
• Many applications work behind the scenes, for
  example, in industrial automation and robotics.
  Since these embedded-controls systems primarily
  execute sophisticated logical and control
  algorithms, you may wish to augment the use-case
  model with state machines, sequential logic
  expressions, or other techniques.
• Applications that parse input strings, compile
  code, or translate from one language to another
  may have significant functional requirements that
  are better expressed in other ways.

21

• In these specific cases the supplementary
  specification can contain functional requirements
  not captured by the use cases.
• 5.5.2 Usability
• May include consideration of
• The required training time for the users
• Specify the existence and required features of
  online help systems, wizards, tool tips,
  context-sensitive help, user manuals, and other
  forms of documentation and assistance
• Anything that will made the application more
  usable for all its intended users.
• 5.5.3 Reliability
• Must consider the necessary reliability level
  required for the application e.g. Mean Time
  Between Failures (MTBF) specified in hours.
• Also recovery from failures must be considered
  (e.g. automatic back-up)

22

• 5.5.4 Performance
• To include considerations of
• Response time average, maximum
• Throughput transactions per second
• Capacity the number of customers or transactions
  the system can accommodate
• Degradation modes the acceptable mode of
  operation when the system is overloaded
• 5.5.5 Supportability
• Supportability is the ability of the software to
  be easily modified to accommodate enhancements
  and repairs (i.e. how to facilitate future
  maintenance).
• E.g.
• Being able to customize the application (e.g. new
  tax rate) without having to write new code
• 5.5.6
• Other constraints (technical), legal issues,
  localisations, purchased components, licensing,
  interfaces (other than main GUI), installation
  and deployment matters etc.

23

• 5.5.7 Example
• See Separate Document for supplementary
  specification sample.
• 5.6 Business Rules
• This section of the specification may contain
  rules (or link to external documents) that are
  specific to the application domain. E.g.
• Rules for a game application (chess, poker rules
  etc.)
• Accounting regulations
• Business rules dictate how a domain or business
  may operate. They are not requirements of any one
  application, although an application's
  requirements are often influenced by business
  rules.
• This section may not be needed for some
  applications.
• 5.7 Glossary
• The Glossary is a list of noteworthy terms and
  their definitions.

24

• It is surprisingly common that a term, often
  technical or particular to the domain, will be
  used in slightly different ways by different
  stakeholders this needs to be resolved to reduce
  problems in communication and ambiguous
  requirements.
• CASE tool is essential.
• See Separate Document for glossary sample.

• 5.8 Other Resources
• Managing Software Requirements A Use Case
  Approach 2nd Ed. by Dean Leffingwell and Don
  Widrig at Addison Wesley

25

• 5.9 Conclusion
• Analysis during a software project is about
  discovering, documenting and validating the
  software requirements.
• It is about the what of the application it is
  not concerned about the how (design).
• In a waterfall approach to software development
  we expect the full software requirements to be
  fully detailed prior to design and coding.
• In an evolutionary approach to software
  development we want the most important
  requirements to be detailed at the beginning of
  the project. These, and the others, will be
  refined, completed as partial design, coding
  testing takes place on some parts of the project.
• Diagrams are rarely sufficient on their own they
  often need to be clarified and detailed in plain
  English.

26

• A suggested specification document layout is
• Vision
• Introduction
• Business Case
• Stakeholders Descriptions and Goals
• Software Overview
• Summary of Software Features
• Functional Model
• GUI Prototype Screenshots
• Use Case diagrams
• Brief Use Cases
• Some Detailed Use Cases
• Some System Sequence Diagrams
• Data Model
• Basic Data Descriptions
• Entity Relationship Diagram
• Behavioural Model
• State Machine Diagrams
• Supplementary Specifications

27

• To help us discover, sometimes document and
  validate the requirements we can use prototyping
  methods (see next chapter)
• Sometimes, areas of the project need to be
  specified to a degree of preciseness and
  correctness that is impossible to achieve using
  diagrams and plain English we must use a formal
  specification language (see the chapter after
  next)