VIEWS: 16 PAGES: 14 POSTED ON: 11/5/2011
Specification Chapter 9 Customers and Their Needs • There are more than one set of “customers” for the requirements/specifications. • The end-users are one of the obvious customers, they need to know if the system will suit their needs. • In addition, the testers need to know that they can test it, the designers need know that they can design it, and so on. Sharpening Requirements into Specification • Requirements are typically more “fuzzy” that specifications. • Specifications lend themselves to systematic analysis. • Analysis of the requirements can find “derived” requirements: requirements that are a direct consequence of other requirements. When the end user “doesn't care” • The end-user doesn’t always care about what the software does in certain situations. • For instance, the end-user won’t care what the software does in some error conditions: as long as it will eventually lead to them getting what they need from the system! • Specifying what the system will do in these situations will prevent the designers from having to figure it out during the “11th hour” of the development cycle! Internal (“system”) errors • Sometimes the system will have “internal” errors: out-of-memory, no disk space left, and so on. • The end-user doesn’t have a clue what to do about these problems, but expect the engineers to provide code to handle it correctly! Using a specification as a test oracle • Specifications provide information to the test group about how the software should respond. • As an oracle, the specification should allow testers to “look up” the results of a test to make sure they are correct. • Sometimes, if enough formalism is used, tests can be generated automatically from a specification. Writing a specification only to discard it • In some instances, the analysis required to write a specification can cause exposure of errors and inconsistencies in the requirements. • After correction and amplification of the requirements document it may be sometimes prudent to throw out the specification and start over! The Uses of Formalism • Formalism can avoid certain problems such as ambiguity, and help enforce correctness, conciseness, and preciseness. • Formalism can be used to allow automation of: – Consistency checking – Test generation – Value checking (inputs and outputs) – Design Informal formalism • There are shades of gray in formalism: it is not a black or white issue. Formalism is derived simply from “form”. • Structured english is a formalism that can help, but falls short of the rigor of mathematical formalism. Nonetheless, it can be useful: If the student id is negative, then print an error message on the console indicating the student id is in error. • This requirement is clear, concise, succinct, unambiguous all because of the “if input-and- value then output-and-value” form, but is still quite readable and understandable by end-users. The opportunity to verify • This process of requirements specification allows engineers to check the requirements. Decomposition and organization of requirements into a formal specification can help “double check” the requirements. • In addition, analysis allows engineers to look “forward” to the design phase to begin identifying design issues. Formal Specification and Design Methods • There are major design methods that begin with formal specifications, of which three will be covered: – Finite state-machine design – Object-oriented design – Structured analysis/Structured design (SA/SD), sometimes called “Data-flow Diagrams”. Finite-state-machine (FSM) design • FSM design begins with a formal description of: – System States (sometimes considered to be “operational modes”). – Stimuli: the conditions the system must respond to. – Responses: the responses the system can make to stimuli. • FSM architectures (such as table-driven architectures) are almost “off-the-shelf” solutions once the states, stimuli and responses are known. Object-oriented design • Object-oriented design begins with formal descriptions of: – The problem set (“problem domain” or “Use Cases”). – Existing frameworks (if any). – The user working model (paradigm). • By working with the frameworks, paradigm and use cases, an architecture (Class hierarchies and collaborations) can be derived. Design with data-flow diagrams • Data-flow diagrams begin with formal descriptions of: – Inputs and expected outputs. – Transformations that can be applied to data. – Relationships between transformations (such as data passed into and out of the transforms) • The translation of data-flow diagrams into an architecture is a mechanical (clerical) process.
Pages to are hidden for
"Specification"Please download to view full document