Download Requirements Specification and Documentation: Techniques and Guidelines and more Lecture notes Software Engineering in PDF only on Docsity!
CHAPTER 5
REQUIREMENTS SPECIFICATION & DOCUMENTATION
SOU RCE OF PP SL IDES :
- S OMM ERVI L LE, I. 2 0 11. SOFTWARE EN GIN EERING. 9 T H^ **_EDN. ADD ISON -WESL EY.
- L AM S WEER DE, A. V. 2 0 1 1. REQUIREM EN TS EN GINEER IN G: FR OM S YSTEM GOALS TO U ML M ODEL S TO SOFTWARE SPECIFICATION. 2 N D_**^ **_ED. WIL EY.
- WEIGERS, K. AN D BEAT TY, J. 2 0 1 3. SOFTWARE R EQUIREM EN TS. 3 R D_**^ ED N. M ICROSOFT PRESS. - BENNETT, M CRO B B AND FARMER: OB JECT O RIENTED SYST EMS ANALYSIS AND DESIGN USING UML, (4 TH EDITIO N), CHAPTER 8 , MCGRAW HILL, 20 1 0.
LESSON OBJECTIVES
- (^) To understand different techniques can be used in requirements specification process
- (^) To evaluate alternative techniques on requirements specification
AS INTRODUCED IN CHAPTER 1 ... Precise definition of all features of the agreed system
- (^) Objectives, concepts, relevant domain properties, system/software requirements, assumptions, responsibilities
- (^) Rationale for options taken Organization of these in a coherent structure Documentation in a form understandable by all parties Resulting product: Requirements Document (RD)
REQUIREMENTS SPECIFICATION & DOCUMENTATION: OUTLINE Types of Specification Notation for Requirements Specification Free documentation in unrestricted natural language Disciplined documentation in structured natural language
- (^) Local rules on writing statements
- (^) Global rules on organizing the Requirements Document Use of diagrammatic notations Formal Specification
- (^) Algebraic approach
- (^) Model-based approach Beyond Functional Requirements
- (^) Specifying quality requirements
- (^) Quality attributes trade-off
Guidelines for Writing Excellent Requirements 5
USER REQUIREMENTS
User requirements specification (sometimes known
as /System Definition Document) are high-level
abstract requirements. They are intended for use by
people involved in using and procuring the system.
User requirements specification usually written in
natural language, with easy-to-understand
diagrams and tables, of what services the system
is expected to provide and the constraints under
which it must operate.
SYSTEM REQUIREMENTS
System requirements specification (for systems with
substantial software components, it was used
interchangeably as Software Requirements Specification)
are more precise and detail descriptions of the system’s
functions, services and operational constraints i.e. it is
an extended version of user requirements
They may be written in structured form of natural
language supported by system models and tables that
developed during analysis.
System requirements are also used by software
designers as the starting point for the system design, so
they are sometimes called “functional specifications”.
They may be the basis of a contract between the system
developer and customer. Therefore should be complete
and consistent specification of the whole system.
REQUIREMENTS SPECIFICATION & DOCUMENTATION: OUTLINE Types of Specification Notation for Requirements Specification Free documentation in unrestricted natural language Disciplined documentation in structured natural language
- (^) Local rules on writing statements
- (^) Global rules on organizing the Requirements Document Use of diagrammatic notations Formal Specification
- (^) Algebraic approach
- (^) Model-based approach Beyond Functional Requirements
- (^) Specifying quality requirements
- (^) Quality attributes trade-off
Guidelines for Writing Excellent Requirements 10
FREE DOCUMENTATION IN UNRESTRICTED NATURAL LANGUAGE
Unconstrained prose writing in natural language (NL) ...
J Unlimited expressiveness
J communicability
J no training needed
How about other advantages? Let’s discuss…
DISCIPLINED DOCUMENTATION IN STRUCTURED NL:
LOCAL RULES ON WRITING STATEMENTS
Use stylistic rules for good NL spec, e.g.
- (^) Identify who will read this; write accordingly
- (^) Say what you are going to do before doing it
- (^) Make sure every concept is defined before use
- (^) Keep asking yourself: “Is this comprehensible? Is this enough? Is this relevant?”
- (^) Never more than one req, assumption, or domain properties in a single sentence. Keep sentences short.
- (^) Use “shall” for mandatory, “should” for desirable prescriptions
- (^) Avoid unnecessary jargon & acronyms
- (^) Use suggestive examples to clarify abstract statements
- (^) Supply diagrams for complex relationships among items
(More in the text book & online research…)
?
DISCIPLINED DOCUMENTATION IN STRUCTURED NL:
LOCAL RULES ON WRITING STATEMENTS (2)
Use decision tables for complex combinations of conditions
input if-conditions output then-conditions binary filling with truth values one case = AND-combination
Systematic, simple, additional benefits ...
- (^) Completeness check: 2N^ columns required for full table
- (^) Table reduction: drop impossible cases in view of domain properties; merge 2 columns differing only by single “T”, “F” => “-”
- (^) Test cases for free (cause-effect coverage) ?
Train receives outdated acceleration command T^ T^ T^ T^ F^ F^ F^ F Train enters station block at speed ^ X mph T^ T^ F^ F^ T^ T^ F^ F Preceding train is closer than Y yards T^ F^ T^ F^ T^ F^ T^ F Full braking activated X X X Alarm generated to station computer X X X X
FIT CRITERIA MAKE STATEMENTS
MEASURABLE
Complement statements by quantifying the extent to
which they must be satisfied [Robertson, 1999]
Especially important for measurability of NFRs
? Spec: Info displays inside trains shall be informative & understandable Fit criterion: A survey after 3 months of use should reveal that at least 75% of travelers found in-train info displays helpful for finding their connection Spec: The scheduled meeting dates shall be convenient to participants Fit criterion: Scheduled dates should fit the diary constraints of at least 90% of invited participants in at least 80% of cases
DISCIPLINED DOCUMENTATION IN STRUCTURED
NL:
GLOBAL RULES ON ORGANIZING THE RD
Grouping rules: Put in same section all items related to
common factor ...
- (^) system objective
- (^) system component
- (^) task
- (^) conceptual object
- (^) software feature
- (^) ...
Global templates for standardizing the RD structure
- (^) domain-specific, organization-specific, company-specific
IEEE STD-830 TEMPLATE FOR ORGANIZING THE RD (2)
- Specific Requirements 3.1 Functional requirements 3.2 External interface reqs 3.3 Performance reqs 3.4 Design constraints 3.5 Software quality attributes 3.6 Other requirements Appendices Index NFRs: development reqs NFRs: interoperability alternative templates for specific types of system NFRs: time/space performance NFRs: quality reqs NFRs: security, reliability, maintainability
Variant: VOLERE template [Robertson, 1999]
- (^) explicit sections for domain properties, costs, risks,
development workplan, ...
REQUIREMENTS SPECIFICATION & DOCUMENTATION: OUTLINE Types of Specification Notation for Requirements Specification Free documentation in unrestricted natural language Disciplined documentation in structured natural language
- (^) Local rules on writing statements
- (^) Global rules on organizing the Requirements Document Use of Diagrammatic Notations Formal Specification
- (^) Algebraic approach
- (^) Model-based approach Beyond functional Requirements
- (^) Specifying quality requirements
- (^) Quality attributes trade-off
Guidelines for writing excellent requirements 20
