Karteikarten
Requirements Engineering
Karten in diesem Stapel (45)
- 1FOUR TYPES OF REQUIREMENTSFunctional
Quality
Process
Platform - 2List some software qualitiesEfficiency
Usability
Security
Reliability
Maintainability - 3Four features of good user stories?Testable
Estimable
Negotiable
Valuable to USERS - 4Differences Between USE CASES and USER STORIES?USE CASES: contain several scenarios, the Happy Day scenario and Secondary scenarios (where things go wrong)
USER STORIES: correspond to a single scenario.
Stories for secondary scenarios develop over time. - 5Three team structures from this course?Egoless
Strict Hierarchy
Chief Programmer - 6What is on the x and y axes of an earned value chart?x-axis time elapsed
y-axis effort - 7What is the difference between re-factoring and re-engineering?Re-engineering involves changing the design documents as well as the code.
Designs deteriorate over time. It's time to re-engineer when it becomes increasingly difficult to add new features to the code. - 8Give two weaknesses of the waterfall model.- requirements are fixed at the start whereas in practice they are often revealed during development when customers gain a better understanding of the problem.
- there are huge costs in changing direction as the whole project may have to be restarted. - 9What should be included in a domain description? (8 things)Introduction
Glossary
Domain Knowledge
Customers and Users
Environment
Existing Procedures
Competing Systems
Similarities with other organisations and domains. - 10What is the difference between functional and non-functional requirementsFunctional Requirements describe everything a user needs to know , inputs outputs, stored data.
Non-functional requirements cover things the user does not need to know. - 11What should be included in a use case?Name: verb phrase -"enrol on course"
Users: "student"
GOAL: "enable the student to enrol"
Pre-condintions: "Student must be registered...
Steps: user input and system response
Post-conditions: state of system after
Related cases. - 12What are the benefits/purpose of Use Cases?Clarify System Purpose
help define the scope of the system.
measure system size
measure progress
help define TEST CASES
Structure user guides
Develop and validate REQUIREMENTS - 13Name a limitation of use casesThey do not cover all requirements - e.g. processes not initiated by the user.
- 14Pros and cons of Top-Down designStart with very high level architecture
Focus on problems to be solved
Eventually get to algorithm level
-ve Does not lead to much reuse of code - 15Pros and cons of Bottom-Up designStart with the little tasks - producing general purpose reusable components.
Integrate smaller components into larger ones.
+ easier to build smaller GP components as no requirements risk.
-ve Produces code with more functionality than needed to solve the specific problem. - 16Two characteristics of a mixed "Meet in the middle approach."Problem specific logic is best designed top-down.
GP components easier to build as no requirements risk. - 17Give an advantage and disadvantage of GP components+ no requirements risk
- limit to how many can be used to solve a specific problem - 18Describe a meet in the middle approach1. Look for components that any solution must have. E.g access control, authentications, I/O
2. The rest of the logic probably needs to built top down depending on the system - 19Describe an alternatives Evaluation Table (Decision making technique)One alternative solution on each row.
Objectives in each column in decreasing order or importance.
List how well they meet of DNMO
Eliminate till one left - 20Requirements are either:A function the system must perform
or
A constraint on the system - 21Cohesion.....keeps related things together and other things out.
- 222 General benefits of CohesionMakes the system:
Easier to understand.
Easier to modify. - 23Functional CohesionModule performs a single computation
Will always give the same output for a given input.
Easy to debug.
NO SIDE EFFECTS if module has full functional cohesion - 24DATA COHESIONCode operating on the same data is grouped together.
OO- related variables in same class
+ all methods operating on data
instance variables and methods working together - STRONG COHESION
database - weaker but more pure - operations on data are elsewhere - 25Sequential CohesionAtomic(indivisible) operation
e.g. money transfer
all performed or none - 26Layer CohesionHierarchy of layers.
Lower layers provide services to higher layers.
Functionality of one type of module is grouped together interface lower levels via API.
Can replace module provided API remains the same. - 27Temporal CohesionWEAK -- prioritise other forms.
Operations performed during the same phase of execution cycle are grouped together. - 28Why is coupling bad?Developer is forced to know about too many things at once.
A change in one module will force changes in others.
Hard to see how particular components work. - 29When does good interdependency(cohesion) turn into bad interdependency(coupling)?When the amount of information that the developer needs to know all at once becomes too much.
2 strongly coupled modules(bad) could be combined into 1 strongly cohesive one(good).
Rule of thumb: Description of a good module should fit on one page. - 30Content CouplingOne component silently modifies data internal to another.
(if it is natural for two components to do this they should be in the same module - cohesion)
Content coupling makes it hard to see how data can be changed from reading the code. - 31GLOBAL VARIABLES (common coupling)BAD: hard to keep track of program logic.
Occasionally useful to have one or two but AVOID if possible.
Tempting to use as avoids passing parameters. - 32CONTROL COUPLINGa component receives a variable that tells it what to do.
Often means this could have been two separate modules(Circle,Square)
Use polymorphism - 33Interface CouplingThe BEST form of coupling between classes.
Classes need to know about and call the methods of other classes in OO.
(similar to Routine Call coupling in Lethbridge) - 34Waterfall Pros and ConsEasy to write contracts
Easy to set milestones
Does not take account of changing requirements
No customer involvement until delivery
Assumes maintenance is just bug fixing (rather than adding new features)
no concept of retirement. - 35Pros and Cons of Phased ReleaseSHARES disadvantages of waterfall
+ if s/w is unsuccessful this will be discovered at phase one so less money wasted.
Similar to waterfall but s/w produced in phases
1st Stage includes requirements capture, specification and planning.
then several phases of Design, implementation and plannin - 36What is the Spiral Software ProcessRepeat waterfall over and over
Review and risk analysis added before each phase
Maintenance is just ongoing development. - 37Main Characteristics of the Agile ApproachLess formal
Iterative with many Small iterations.
Close delivery dates for each iteration.
Avoids generation of much paperwork.
Good for small projects with high requirements risk.
If wrong direction taken it is not a disaster.
Saves ££££$$$$$$ - 38eXtreme Programming outlineDevelopment team includes ALL stakeholders
Requirements capture with USER STORIES
USER stories put into iterations - 39two disadvantages of eXtreme programming1. Scalability
2. Harder to write contracts - 40Pair programming is encouraged in XP, what are the pros and consEgo-less
No owner of any piece of code
difficult to make work well - 413 Project variables in eXtreme programmingScope
Resources
Time
Time is dependent on Scope and Resources
(Quality is not a variable: it is fixed) - 42Acceptance testing in Agile/XP based on......USER STORIES , the user story must work as expected.
- 43REgular Refactoring is encouraged in XP, what does it involve?Reorganisation of the code
small pieces remain the same but methods may move between classes and new classes created
inheritance might be added
new patterns might be added. - 44How might the customer's willingness to share in the development process influence the choice of design approach?Will customer share in development process?
Yes - Agile might be appropriate
No- Requirements capture and get sign off from customer. If they want to change later they have to pay. - 45Structure of Requirements DocProblem
Background
Environment
Requirements
Informationen
- Beschreibung
- Karteikarten am Requirements Engineering, erstellt von Tom Reed am 17/05/2015.
- Erstellt von
- Tom Reed
- Aufrufe
- 2
- Bewertung