1 / 11

Requirements Elicitation and Analysis Process

Learn about the requirements elicitation process and analysis techniques to accurately document software requirements. Understand different types of requirements and how to resolve conflicts. Use UML modeling notations to effectively communicate and specify requirements.

lreed
Télécharger la présentation

Requirements Elicitation and Analysis Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements (recap)‏ • Requirements = desired behaviour • Process • Elicitation (extracting requirements from stakeholders)‏ • Analysis Everything documented in the requirements document

  2. 4.3 Types of Requirements • Functional requirement: describes required behavior in terms of required activities • Quality requirement or nonfunctional requirement: describes some quality characteristic that the software must possess • Design constraint: a design decision such as choice of platform or interface components • Process constraint: a restriction on the techniques or resources that can be used to build the system

  3. Non-functional: describes a restriction or constraint that limits our choices for constructing a solution Examples: Response time, processor usage, etc. Reliability, availability Functional vs. non-functional requirements • Functional: describes an interaction between the system and its environment • Examples: • Inputs and outputs (format, completeness, user interfaces)‏ • Response to every input incl. invalid input • Specify correct outputs and special cases

  4. 4.3 Types of RequirementsSidebar 4.4 Making Requirements Testable • Specify a quantitative description for each adverb and adjective • Replace pronouns with specific names of entities • Make sure that every noun is defined in exactly one place in the requirements documents (glosary of terms)‏

  5. 4.3 Types of RequirementsResolving Conflicts • Different stakeholders have different sets of requirements • potential conflicting ideas • Need to prioritize requirements Ex: • essential: absolutely must be met • desirable: highly desirable but not necessary • optional: possible but could be eliminated

  6. 4.3 Types of RequirementsTwo Kinds of Requirements Documents • Requirements definition: a complete listing of everything the customer wants to achieve • Describing the entities in the environment where the system will be installed • Requirements specification: restates the requirements as a specification of how the proposed system shall behave from the point of view of the developer

  7. 4.3 Types of RequirementsTwo Kinds of Requirements Documents (continued)‏ • Requirements defined anywhere within the environment's domain, including the system's interface • Specification restricted only to the intersection between environment and system domain

  8. 4.5 Modeling Notations • It is important to have standard notations for modeling, documenting, and communicating decisions • Modeling helps us to understand requirements thoroughly • Holes in the models reveal unknown or ambiguous behavior • Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements

  9. 4.5 Modeling NotationsUML Class Diagram • UML (Unified Modeling Language) is a collection of notations used to document software specifications and designs • It represents a system in terms of • objects: akin to entities, organized in classes that have an inheritance hierarchy • methods: actions on the object's variables • The class diagram is the flagship model in any UML specification • A diagram relating the classes (entities) in the specification

  10. Use case diagram • General view of use-cases for your system. • Shows relationship between use-cases • Used during analysis (completeness, clarity)‏

  11. Modeling the dynamic behavior of entities • Interaction diagrams • How different objects/entities interact • State-chart diagrams • Behaviour of one object/entity • Activity diagram • Flow of data/control Think of UML diagrams as your tools that help you analyze and specify requirements

More Related