Fichas
Requirement engineering definitions
Fichas del conjunto (92)
- 1Misuse casesA sequence of of actions, including variants, that a system can perform, interacting with misusers and causing harm to some actors if the sequence is allowed to complete
- 2Anti-requirementsRequirements of a malicious user that subverts an existing requirement.
- 3Secure-I*Enrich the semantics of I* in order to address security requirements modelling and analysis
- 4RequirementDesirable property of something to be tested.
- 5Ubiquitous requirementsRequirement is always active, no pre-conditions or triggers.
- 6State-driven requirementsActive whilst pre-condition holds
- 7Event-driven requirementsRequired response to a triggering event
- 8Requirement numberUnique identifier for development and traceability purposes.
- 9Requirement typeEnables us to categorise the requirements for different purposes.
- 10Event/Use caseThe context of the requirement is broken into smaller pieces using business events in use cases.
- 11RationaleThe reason behind the requirement's existence. Helps you to clarify and understand.
- 12SourceThe name of the person or group who raised the requirement in the first instance.
- 13Fit criterionQuantified goals that the product has to meet - they are the acceptance criteria.
- 14Customer satisfactionThe satisfaction ranking is a measure of how happy the client will be if the product successfully delivers an implementation of the requirement.
- 15Supporting materialsOther material important to the requirements that are referenced to.
- 16HistoryA record of the date the requirement was first raised, dates of changes, date of deletion, dates of consolidation of the requirement, etc.
- 17Functional requirementSomething (service, behaviour or function) that a product must do.
- 18Non-functional requirementsExpress the desirable qualities of the product.
- 19Performance (time to do things)Response time
Throughput rates - 20Reliability (Required levels of failure supported in product)Mean-time between (defined) failures.
- 21Usability (Usability evaluations, protocol analysis and cognitive walkthroughs).Usage rates
Error rates - 22Look-and-feel (how end-users perceive the product)Adherence to standards, colour and designs.
- 23Device (non-software features like weight and size)Adherence to specified standards
- 24Accuracy (Desirable levels of accuracy of some output or functioning of an actor)Data of object of requirement
Analysis of this data using precise mathematical techniques. - 25Portability (platform system operates on)Measured using names and versions of products and operating systems
- 26TrainingTraining duration and outcomes
- 27Maintainability (acceptable levels of upgrade and change to the product)Time required to complete a maintenance and/or the resources needed to undertake a maintenance.
- 28Recoverability (required time and resources need to recover from specified types of failure)Recover times, costs and people needed to recover.
- 29Security (acceptable levels of illegal access to the product)Mean-time between breaches
Frequency of breaches - 30Safety (how safe a product must be to use and operate)Number of actual or predicted injuries and death over a period of time.
- 31Software monitorA software system that observes another target system's behaviour for qualities of interest.
- 32Requirements monitorDetermines the requirements status from a stream of significant input events.
- 33Requirements monitors operationalise measurable fit criteria1. Select which types of event to capture
2. Determine how to interpret event information
3. Analyse event information to construct models
4. Compare models to requirements fit criteria - 34Requirements engineeringThe branch of systems engineering concern with the real-world goals of, services provided by, and constraints on software-intensive systems.
It is also concerned with the relationship of these factors to precise specifications of system behaviour, and to their evolution over time. - 35User requirementsDesirable properties of the domain, independent of the system, expressed by users and other types of SHs.
- 36System requirementsDesirable properties of the system introduced into domain.
- 37Satisfaction argumentsGiven properties of Domain D, combined with the specification of the behaviour of a system S, requirements R will hold.
D, S |= R - 38ModelA simplified version of something complex used in analysing and solving problems or making predictions.
- 39Use of ModelsGuide elicitation
Provide a measure of progress
Help to uncover problems
Help us check our understanding. - 40Use caseA description of a set of actions, including variants, that a system performs that yields an observable result of value to a particular actor.
- 41ScenarioA sequence of actions that illustrates behaviour.
- 42Use case diagramDepicts system's content and system's main use cases.
- 43Use case IDUnique ID for Use case.
- 44AuthorName of author.
- 45DateDate use case was written.
- 46SourceSource of use case.
- 47ActorsActors involved in use case (from use case model).
- 48PrecisAn informal scenario description.
- 49AssumptionsExplicit statement of any assumptions made in writing the use case.
- 50PreconditionsNecessary conditions for the use case to occur.
- 51Normal courseThe most frequently-occuring sequence of actions leading to the achievement of the user actor's goals.
- 52Alternative coursesAre events that, if not handled through new specifications of system intervention, will lead to the use case requirement not being met.
- 53Variation courseAre events other than the normal course events that lead to the achievement of the use case requirement or goal
- 54Elements of requirement monitor- Model repository
- User model and diagnostic model
- Event filter
- Event source / Recorders - 55Added valueBenefit of use case above and beyond the original scenario and original system.
- 56Functional requirements (use case)Requirements that the use case decomposes.
- 57Non-functional requirements (use case)Requirements that impose constraints on the required behaviour in the use case.
- 58Agile problems in requirement phase- Surrogate users
- Difficult to achieve consensus
- Poor handling of quality requirements
- Prototypes tend not to scale. - 59Context diagramDescribes the boundaries of a socio-technical system. It's a data-flow diagram (DFD).
- 60Strategic dependency (SD) modelModels requirements-related dependencies between strategic actors in the future system.
- 61Strategic rationale (SR) modelModels rationale, decompositions and contribution links between important goals of different system actors.
- 62Intentional strategic actorIntentional aspects such as objectives, rationale and commitments
- 63GoalCondition or state of the world that can be achieved or not.
- 64Soft-goalGoals that cannot be so sharply defines, such as goals that describe properties or constraints of the system being modelled.
- 65TaskOne particular way of attaining a goal - a detailed description of how to accomplish a goal.
- 66ResourcePhysical or informational objects in the world available for use in a task.
- 67Goal dependencyDepender depends on the dependee to be able to bring about certain state in the world.
- 68Softgoal dependencyDepender depends on dependee to perform some task that meets the softgoal or to perform the task in a particular way.
- 69Task dependencyDepender depends on dependee to be able to carry out task.
- 70Resource (SD)Depender depends on dependee for the availability of entity.
- 71Softgoal and goal dependencies delegationFull delegation.
- 72Task dependencies (delegation)Partial delegation.
- 73Resource dependencies (delegation)Minimum delegation.
- 74Task decomposition linksDecompose task into sub-components of all types.
- 75Means-end linksA relationship between an end and a means for attaining the end.
- 76Contributes-to soft goal linkA means-end link with a softgoal as the end.
- 77How to produce SR model1. Model what each actor can accomplish itself
2. Model what each actor depends on other actors for
3. Integrate the single-actor SR models together - 78Requirements elicitation objectives- Understand the system and its context
- Identify problems and opportunities calling for new system
- Discover the real needs of stakeholders with respect to new system
- Explore alternative ways in which the new system could be specified - 79Stakeholder's explicit needsNeeds that stakeholders state explicitly; they're often symptomatic of some problematic situations to be fixed.
- 80Stakeholder's hidden needsNeed that stakeholders fail to mention because they know so much about them and assume everyone has the same knowledge.
- 81Stakeholder's undreamed of needsThings that the stakeholders don't realise are possible.
- 82Requirements elicitation difficulties- Distributed sources of information
- Difficult access to sources of information
- Conflicting information
- Communication difficulties
- Tacit knowledge and hidden needs
- Bias and socio-political factors
- Unstable conditions - 83Elicitation techniques - Traditional- Interviews
- Questionnaires
- Surveys
- Analysis of existing documentation - 84Elicitation techniques - Collaborative- Brainstorming
- RAD/JAD workshops
- Prototyping - 85Elicitation techniques - Cognitive- Protocol analysis
- Cardsorting
- Laddering - 86Elicitation techniques - Contextual-Ethnographic techniques
- Discourse analysis
- Observation - 87Elicitation techniques - Creativity- Creativity workshops
- Analogical reasoning - 88Validation of requirementsThe investigation of the specified requirements against stakeholder's perception of their requirements to determine whether the correct requirements have been specified.
- 89Verification of requirementsThe investigation of requirements models and specifications to discover undesirable properties of these specifications.
- 90Quality criteria for requirementsComplete
Traceable
Correct
Unambiguous
Comprehensible
Consistent
Verifiable
Rated
Up to date
Atomic - 91Impact scenariosProjections of future system use in the environment.
- 92VersionThe identifier of the current/latest version of the requirement.
Información
- Descripción
- Fichas sobre Requirement engineering definitions, creado por deborah.durojaiy el 13/01/2016.
- Creado por
- deborah.durojaiy
- Visitas
- 0
- Valoración