COSC 4506/ITEC 3506 Software Engineering Specification Phase

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

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%,

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?

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.

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!

Semi-Formal Specification Why? Why not?

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.

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)

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.

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.

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

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

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

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

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

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

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”

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

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}

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

Z (“zed”) Notation

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

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

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