Reqs analysis
•
0 recomendaciones•315 vistas
Requirement Analysis (Software Engineering)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Reqs analysis
Similar a Reqs analysis (20)
Más de Dr. C.V. Suresh Babu
Más de Dr. C.V. Suresh Babu (20)
Último
Último (20)
Reqs analysis
- 1. Requirements Analysis & Requirements Specification
- 2. Requirements Engineering Requirements Elicitation Requirements Analysis Requirements Specification Requirements Verification Requirements Management Requirements Engineering
- 5. What vs. How Dilemma 3 User Needs System Requirements System Design Software Requirements Software Design What How What How What How What How
- 6. Requirements vs. Design Customer not interested (Most of the time) except for external Customer interested There is only one (final) solution There is more than one solution Primary goal of design: OPTIMIZATION Primary goal of analysis: UNDERSTANDING Describe how it will be done Describe what will be delivered Design Requirements
- 14. Product Overview (4.) (at last!) 4.2 Summary of Capabilities Customer Benefit Supporting Features 1. 2. 3. 4.
- 15. Product Overview (4.) (at last!) 4.3 Assumptions and dependencies What factors affect the features above? List assumptions that, if changed , ALTER this document 4.4 Cost and pricing -- not done by engineering 4.5 Licensing and installation -- different types of license enforcement will create more requirements for the development effort
- 16. What’s a feature? - high level capability necessary to deliver benefit to the user - externally desired service that typically requires inputs to achieve Level of detail must be general -- this is not the requirements spec for the developers. Provide the basis for product definition , scope management , and project management . Each will be expanded in the use-cases or other requirements Externally perceivable by users or external systems Product Features (5.)
- 21. Vision Doc adds basis for SRS
Notas del editor
- These are the five activities involved in sw req engineering.
- 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
- 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.
- “ 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.
- 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.
- 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)
- *deliverables are project deliverables or OUTPUTS from the system under development
- Note: The capabilities produce benefit to the customer. List the benefits.
- Example of assumptions: Prototype hardware available for software testing by date X COTS touch screen available with washable glass front – found by date Y
- These have been mentioned in the Customer Benefits but are summarized here as a list of features. Examples of features:
- “ 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).
- Note which items in SRS can be copied or at least strongly based on the Vision Doc.
- Section 3 – organized by stimulus/response
- One way to think about component design (later) will be to organize the use cases by Primary Actor .
- The precondition is not the first step of the use case. It is what has taken place before the first step.
- Develop use case for enhancement Apply to Vision Document Eventually, we will look at these other representations