1. COSC 4506/ITEC 3506 Software Engineering
Specification Phase

2. Outline What is Specification? Three types Informal specifications
Semi-formal
Use cases
Structured systems analysis
Entity-relationship diagrams
Formal
Finite state machines
Z notation

3. Informal Specifications
Written in natural language (e.g., English)
Example
“If sales for current month are below target sales, then report is to be printed, unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is under 5%”
Read the statements at the top of page 252
Let’s look at an example Write on board
Sales target for January was $100,000, actual sales were only $64,000 (36% below target)
Action? print report
Sales target for February was $120,000, actual sales were only $100,000 (16.7% below target)
percentage difference for February (16.7%)
Action: do not print report Why? less than half of previous month’s percentage difference (36%),
Sales target for March was $100,000, actual sales were $98,000 (2% below target)
Action: do not print Why? percentage difference < 5%,

4. Informal Specification Example
Sales target for January was $100,000, actual sales were only $64,000 (36% below target)
print report
Sales target for February was $120,000, actual sales were only $100,000 (16.7% below target)
percentage difference for February (16.7%) less than half of previous month’s percentage difference (36%), do not print report
Sales target for March was $100,000, actual sales were $98,000 (2% below target)
percentage difference < 5%, do not print
What questions arise from the requirements statement?

5. Informal Specification Example
Important details are missing or ambiguous!
“difference between target sales and actual sales”
Ambiguous: How to calculate difference? (% or $)
If % don’t print but if $
$20K (Feb) is not less than half of $36K (Jan)  report is printed!
“difference … [of] 5%”
Inconsistent: no mention of percentage in the rest of spec
May lead to assumption that rest of spec means that % is used to compare differences should whereas perhaps the intent was something else.

6. Informal Specifications
Natural language is not a good way to specify products
 Informal style is poor!
doesn’t matter if you use professional spec writers
Fact
many organizations still use NL (with some structure such as numbered lists)
Reasons
How come we always have time to do it over but we don’t have time to do it right!

7. Semi-Formal Specification
Why?
Why not?

8. Pseudo-code Example: Check project project plan check_plan (report)
if report (date_time) > due_date_time then error (too_late)
if report (client) = none then error (no_client)
if report (team) < min_team or > max_team
then error (bad_team)
if error() = none
then comments = read_report (report)
return (comments (text), comments (grade))
else return error()
Pseudo-code is used at the detail level in use case narratives and in process specifications in structured DFD models.

9. An Introduction to Requirements Modeling
Challenges:
elicit the correct and necessary system requirements
specify them in a manner understandable to ’users’
Verify and validate.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is a difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. Fred Brooks (No Silver Bullet)
Notes:
Can you think of some real-life experiences where you have experienced misunderstood or mis-specified system requirements. (Not system – but what about I’ll pick you up at Sears –without specifying the door)
(It needs to be “red” – as a verbal statement – might mean “color or action of reading)

10. Benefits of Use-Case Modeling
tool for capturing functional requirements.
Aids user help and system documentation.
starting point for identifying data objects or entities.
specifications for user and system interfaces.
Aids defining database access requirements.
Notes:
use-case modeling encourages user involvement.
for use cases to be successful participation by the user is imperative.

11. Concepts for Use-Case Modeling
Use-case diagram – depicts the interactions between the system and external systems and users.
Use case –a scenario (related sequence of steps), (automated or manual), that perform a single task.
Description of system functions from the perspective of external users in terminology they understand.
Notes
use-case diagrams and use-case narratives are two views of the same sequence of steps that make up a conceptual use-case.
use-case diagram communicates at a high level the scope of the business events that make up the Use-case.
use-case narrative communicates at a more detailed level exactly how the user interacts with the system.
A use-case itself is not (usually) a functional requirement, but the use-case’s story, or scenario, will demonstrate or define one or more requirements.

12. Sample Use-Case Model Diagram
Notes:
The ellipse is use to show as single “use case” or subset of the overall system functionality
The “stick figure” is used to represent an “actor” which is anything that needs to interact with the system to exchange information. (external to the system)
Could be a human, an organization, another information system, an external device, or even time.
If the external “thing” is a not a person, for example a specific time which “triggers” an event in the use case, it is still represented as an actor (called the “time” actor and the event is called a “temporal” event)
Represented graphically by a horizontal ellipse with the name of the use case

13. Entity-Relationship Diagrams
Semi-formal technique
Focuses on data rather than actions
Widely used for specifying databases
Also used for object-oriented analysis
Author 1
Reader
Autobiography n
writes
reads
owns
1 to many
relationships
Part
is supplied by
Supplier m n
many to many
relationships

14. Data-Flow Models External entities Processing steps
Data stores or sources
Data flows

15. Example: University Admissions
Rejection
Application
form
Completed
application
Receive
application
Evaluate
Applicant
Offer
Level “n”

16. Example: University Admissions Assemble Application Stage
Acknowledgment
Acknowledgment
Application
form
Completed
application
AND
Evaluation
request
Initiate
evaluation
Receive
Applicant
AND
Supporting
information
Level “n+1)
Applicant
database
Pending
database

17. Formal Specification Why?
• more precise standard to define and validate software
Why not?
• May be time consuming
• Methods not suitable for all applications

18. Finite State Machines Formal method
5 parts: states, inputs, transition, initial state, set of final states (can also add predicates)
See p. 319: This is an important requirements modeling approach for real-time (process systems) – e.g. ABS brakes, ATM authorization, etc. where there is a specific setof states and many possible inputs – if not well specified can easily generate unwanted states and/or “crashes”

19. Finite State Machines Formal method
5 parts: states, inputs, transition , initial state, set of final states (can also add predicates)
Current
State
Dial
Movement
Safe Locked A B 1L 1R 2L 2R 3L 3R
Sound Alarm
Safe Unlocked

20. Finite State Machines
5 parts: states, inputs, transition , initial state, set of final states (can also add predicates)
Set of states J: {Safe Locked, A, B, Safe Unlocked, Sound alarm}
Set of input K:{ 1L, 1R, 2R, 3L, 3R}
Transition function T
Initial state S : Safe Locked
Set of final states F: {safe unlocked, sound alarm}

21. Finite State Machines Advantages
more precise than DFDs (almost as easy to understand)
easy to write down, validate, & convert into code
some CASE tools directly generate code from FSMs
makes maintenance easy -> changes spec & regenerate
Disadvantages
number of triples (state, event, predicate) grows rapidly
does not deal with timing issues

22. Z (“zed”) Notation

23. Comparison of Specification Techniques
Choose method most appropriate for product
Formal methods
powerful and precise
difficult to learn & use
could be useful where cost/safety/reliability is important
Informal methods
little power
easy to learn and use
Trade-off
ease of use vs. power

24. Testing the Specification
Specification inspection
inspectors use a checklist of items to look for
can also trace items back to requirements doc
record faults found & rate of finding faults

25. Summary Specification document ?
explicitly defines functionality & constraints
3 Types ?
informal
e.g., NL
very ambiguous, but easy to understand
semi-formal
e.g., DFD, E-RDs
easy to understand, but more precise
formal
e.g., FSMs, Z
very precise & powerful, but hard to learn
useful where safety or reliability is a concern