Download
1 / 11
110 likes | 115 Views
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.
E N D
Requirements (recap) • Requirements = desired behaviour • Process • Elicitation (extracting requirements from stakeholders) • Analysis Everything documented in the requirements document
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
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.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)
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
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
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
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
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
Use case diagram • General view of use-cases for your system. • Shows relationship between use-cases • Used during analysis (completeness, clarity)
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
