SOEN 341 Week 5
What are Functional requirements main concerns?
Imprecision: -Development teams have a knack for addressing ambiguous requirements with the simplest solution to implement -Imprecision may lead to a solution that does not match user expectations Completeness: -Should describe all of the system features that are required Consistency: -Conflicts or contradictions among requirements should be avoided
Ways of writing a system requirements specification: Graphical notations
Models, supplemented by text annotations, are used to define the functional requirements for the system; UML use case and sequence diagrams are commonly used.
What is a non-functional requirement?
Non-functional requirements: -Specify properties and constraints of the system - e.g. reliability, response time and storage requirements -Typical form: "The system shall/should be ..." -Although often overlooked, NFRs may be critical to the success/failure of a system Example:The Mentcare system shall be available to all clinics during normal working hours (Mon-Fri, 0830-17.30). Downtime within normal working hours shall not exceed five seconds in any one day.
What are non-functional requirements main concerns?
Quantifiability: -Goals like "system should be bug-free" are noble, but impractical to validate! -We need to make it a measurable requirement!
What is the Find The Test (in terms of requirement quality)?
The "find the test" check: -Can a test for the requirement be easily defined? Is that a meaningful test? If not, it is a BAD requirement! Example: The system shall be reliable.
Guidelines for writing requirements
•Invent a standard format and use it for all requirements. •Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements. •Use text highlighting to identify key parts of the requirement. •Avoid the use of computer jargon. •Include an explanation (rationale) of why a requirement is necessary.
What are the disadvantages of natural language requirement definitions
•Lack of clarity -Precision is difficult without making the document difficult to read. •Requirements confusion -Functional and non-functional requirements tend to be mixed-up. •Requirements amalgamation -Several different requirements may be expressed together.
What are the Natural language specifications?
•Requirements are written as natural language sentences supplemented by diagrams and tables. •Used for writing requirements because it is expressive, intuitive and universal. •This means that the requirements can be understood by users and customers.
What must the Anatomy of a good requirement include?
-Defines the system being discussed -Verb should be: "shall" or "should" -Quality criteria is listed -Defines a positive end result Example: The online banking system shall allow the user to access their current account balance in less than 5 seconds
What are the two key types of requirements?
1.Functional requirements 2.Non Functional Requirements
What are the Key requirements doc components?
Each requirement must be defined: -Often, these definitions appear in a list -Each requirement is given a unique ID to allow traceability
How to measure the Non-functional requirement metric: Portability
Percentage of target dependent statements Number of target systems
Ways of writing a system requirements specification: Mathematical specifications
These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don't understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract
Ways of writing a system requirements specification: Design description languages
This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.
How to measure the Non-functional requirement metric: Ease of use
Training time Number of help frames
What are the advantages of structured text requirement definitions?
Uniformity: -Ensures uniformity while still being flexible -Granted, less so than free-form text -Keep in mind that there is still Ambiguity
Some Pitfalls to avoid
What vs. how: -Never describe how the system should deliver the requirement Focus on what the system should do Example: BAD:The system shall use Microsoft Outlook to send a confirmation email to the customer. GOOD:The system shall inform the customer of an order confirmation within 2 minutes.
NFRs as User Stories
•We could try to address them like this: •As a user, I want to have a response from the system after at most 1sec so that I do not waste my time. •As a system administrator, I want to be able to run 1000 users in parallel so that I can deploy the system in our company. •(This is what some Scrum people propose - Issues?) •Some propose writing NFRs as user stories - they are at least captured, but do not fit into the sprint/estimation model •Some propose to capture them in a different format (e.g., templates specifically for NFRs) - but then you need a new strategy for integrating them into your sprint planning SOME SAY IGNORE NFRs
What is a software requirement?
(1)A condition or capability needed by a user to solve a problem or achieve an objective. (2)A condition or capability that must be met or possessed by a system[...] to satisfy a contract, standard, specification, or other formally imposed document.
What must the Anatomy of a bad requirement include?
-Avoid requirements on users -Vague quality criteria -No identifier for the verb -"What" vs. "How" Example: The user quickly sees their current account balance on their laptop screen
What is a negation check (in terms of requirement quality)?
-Would the opposite case be a quality that some systems might like to have? If not, it is a BADrequirement! Example: The car shall have an engine. Is there any car that does not have an engine? The car does not have an engine - is it possible? Requirements shouldn't be too general
What are the Characteristics of good requirements?
Complete sentences! -Not a list of buzzwords and acronyms Use plain language! -"The system shall utilize an alphabetical schematic to organize records" NO! -"The system shall organize records alphabetically" YES! Subject and predicate: -Subject = system being discussed -Predicate = a condition, action, or intended result -Verb in predicate: -"Shall" = mandatory -"May/Should" = optional Realism (Feasibility): -Avoid wishful thinking Validity(Necessity): -Provides the details of the desired end goal Verifiability(Testability): -Contains quantifiable success criteria Consistency: -no conflict Completeness: -All functions
Some Pitfalls to avoid Prt2
Escape clauses: -Danger signs: "if", "but", "when", "except", "unless", "although" Ambiguity: -Danger signs: "or", "etc", "and so on" Vague, undefinable terms: -Danger signs: "user-friendly", "highly versatile", "flexible", "approximately", "as much as possible" Conjunctions: -One requirement per sentence -Danger signs: "and", "or", "with", "also" Speculation: -Danger signs: "usually", "generally", "often", "normally", "typically" Wishful thinking: -Danger signs: "100% reliable", "bug-free", "handle all failures", "run on all platforms"
What are Functional Requirements?
Functional requirements: -Describe what the system should do -Typical form: "The system shall/should do ..." -Functional user requirements: -High-level statements about system behaviour -Functional system requirements: -Describe system behaviour in detail •Problems arise when functional requirements are not precisely stated.
How to measure the Non-functional requirement metric: Size
Mbytes Number of ROM chips
How to measure the Non-functional requirement metric: Reliability
Mean time to failure Probability of unavailability Rate of failure occurrence Availability
How to measure the Non-functional requirement metric: Speed
Processed transactions/second User/event response time Screen refresh time
What are the high-level classification Non-functional requirements?
Product requirements: -The delivered product must perform in a certain way Organizational requirements: -Process constraints, e.g., standards that must be followed External requirements: -Non-product, non-organizational -E.g., Interoperability, legal
Which one is not a step in requirement engineering? 1.Requirement elicitation 2.Requirement validation 3.Requirement classification 4.Requirement analysis 5.Requirement specification
Requirement analysis
Ways of writing a system requirements specification: Structured Natural Language
The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement
Ways of writing a system requirements specification: Natural Language
The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.
How to measure the Non-functional requirement metric: Robustness
Time to restart after failure Percentage of events causing failure Probability of data corruption on failure
User vs. system requirements
User requirements: -Describe the services the system is expected to provide EX:The system shall generate monthly management reports showing the cost of drugs prescribed by each clinic System requirements: -Detailed descriptions of system functions and operational constraints. EX:On the last working day of each month, a summary of the drugs prescribed, their cost and the prescribing clinics shall be generated.
What are User Stories?
User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. Often used in agile software development models •As a <type of user>, I want <some goal> so that <some reason>. •User stories are often written on index cards or sticky notes, and arranged on walls or tables to facilitate planning and discussion.
What are the advantages of natural language requirement definitions
Well-established practice: -It's been used forever! -Still broadly adopted in industry Flexible: -Free-form text allows for almost any requirement to be expressed
What are ambiguous requirements?
•Ambiguous requirements may be interpreted in different ways by developers and users. •Ambiguous requirements: -A user shall be able to search the appointment lists for all clinics. •User intention - search for a patient name's across all appointments in all clinics; •Developer interpretation - search for a patient name in an individual clinic. User chooses clinic then search.
What are Structured specifications?
•An approach to writing requirements where the freedom of the requirements writer is limited and requirements are written in a standard way. •This works well for some types of requirements e.g., embedded control system -sometimes too rigid for writing business system requirements.
What is Requirements engineering:
•The process of establishing the services that a customer requires from a system and the constraints under which it operates and is developed. •The system requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process.