Reqs analysis

Editor's Notes

1. These are the five activities involved in sw req engineering.
2. The precision to which Requirements are specified is a function of Expertise of developers Knowledge developers and testers have of the domain – the more they know, the less specific the specification needs to be Access to a domain representative For example, in xp, requirements may be specified in less detail but there is a customer representative on site daily. NOTE various test methods. “Objectively verified” is referring to testing by various methods: Inspection, demonstration, analysis, test
3. We learn what the user needs are. We propose how to address them by defining system requirements. We specify what we are going to build in system requirements. We describe how to address this by designing the system. The system design says what we are going to build. The software requirements tell how we will build part of the system in software. The software requirements tell what we will build in software. The software design how we are going to structure the software. The software design tells what software structure we will build. The code tells how this will be implemented.
4. “ Primary goal of analysis is UNDERSTANDING” … and clarity. There is more than one solution: There is more than one way to address the same requirements. Customer interest: EXTERNAL design – fuzzy area between requirements and design. Customer is interested in design choices that are visible.
5. This comes from “Software Quality Measurement …” Correctness seems overly obvious if viewed as list of quality attributes. Like, what else would you want?? But it makes sense to have it in the list when viewed as measures of quality . Reliability Rating = “three 9’s” or “six 9’s” If I have 1 error per 1000 lines of code, that’s .001. 1 - .001 = .999 hence the phrase “three 9’s” There are other ways of thinking about reliability – bathtub curve, MTTF, often not applied to software. The “n 9’s” definition of reliability is confusing some notions: Reliability connotes how long it runs without failing. errors/LOC is a static attribute of found errors One customer may take certain paths thru the code that don’t fail. Another’s paths do. Operational Profiles provide a better measure of reliability. It is based on probability of usage and allows for a way to predict MTBF.
6. Stakeholder Name - stakeholder type Represents - What they represent with respect to the development . Role - the role they are playing in the development . User: Name - the user type Description - describe what they represent with respect to the system. Stakeholder - how the user is represented by the stakeholders (represented by stakeholder 1.1)
7. *deliverables are project deliverables or OUTPUTS from the system under development
8. Note: The capabilities produce benefit to the customer. List the benefits.
9. Example of assumptions: Prototype hardware available for software testing by date X COTS touch screen available with washable glass front – found by date Y
10. These have been mentioned in the Customer Benefits but are summarized here as a list of features. Examples of features:
11. “ hardware platform” in this context refers to a computer where the software product will execute. In embedded system, system requirements are then divided among hw and sw. A particular platform may be a requirement or it may be part of the proposed solution (design).
12. Note which items in SRS can be copied or at least strongly based on the Vision Doc.
13. Section 3 – organized by stimulus/response
14. One way to think about component design (later) will be to organize the use cases by Primary Actor .
15. The precondition is not the first step of the use case. It is what has taken place before the first step.
16. Develop use case for enhancement Apply to Vision Document Eventually, we will look at these other representations