User
A person who uses the Functionality provided by a System.
Note: Users (also called end users) always are Stakeholders of a System.
-
Manuals Overview
-
Scope and Objectives
- How to define a Project Scope?
- How to identify external systems in a project?
- How to identify the main objective of a project?
- How to define the boundaries of project?
- How to identify the high-level features or functionalities for a project?
- How to identify the stakeholders?
- How to identify regulatory or compliance considerations?
- How to identify the risks associated with a project scope?
-
User Requirements
-
Technical Requirements
- How to define performance requirements?
- How to define the technology stack to be used?
- How to define the necessary scalability of a system?
- How to define the API needs?
- How to define the hardware requirements?
- How to identify technical limitations of a technology stack?
- How to define the deployment strategy?
- How to define backup and recovery plans?
- What are the security requirements?
- How to define the data storage and management requirements?
-
Validation and Verification
-
Budget and Timeline
-
Communication and Documentation
- How to identify key points of contact for requirements?
- How to choose the best tools for requirement management?
- How to maintain and update requirements documents?
- How to communicate changes in requirements?
- How often hold stakeholder meetings?
- How to define a sign-off process for finalizing requirements?
- How to define documentation required for verification and validation?
-
Acceptance and Testing
-
Modeling and Diagrams
- How to model requirements?
- How to model Use Case Diagrams & Use Case Models?
- How to model Object Diagrams & Object Models?
- How to model Entity-Relationship Diagrams & Entity-Relationship Models?
- How to model Feature Diagrams & Feature Models?
- How to model State Diagrams, State Machines, Statecharts, State Machine Diagrams & State-transition Diagrams?
- How to model Activity Diagrams & Activity Models?
- How to model Data Flow Diagrams?
- How to model Sequence Diagrams?
-
Epics, User Stories and Features
- How are Epics, User Stories and Features linked to each other?
- Are acceptance criteria defined for each User Story and Feature?
- How do we decide when an Epic should be broken down into User Stories or Features?
- How do we handle cross-cutting concerns across multiple Epics or Features?
- Are the Epics and Features aligned with business goals and objectives?
-
Glossary
- Glossary
- Acceptance
- Acceptance criteria
- Acceptance test
- Activity
- Activity diagram
- Activity model
- Actor
- Adequacy
- Agile
- Ambiguity
- Application domain
- Artifact
- Association
- Attribute
- Backlog
- Baseline
- Behavior
- Behavior model
- Branch
- Bug
- Burndown chart
- Business requirement
- Cardinality
- Change control board
- Change management
- Change request
- Class
- Class model
- Commonality
- Completeness (of requirements)
- Compliance
- Component
- Composition
- Configuration
- Conformity
- Consistency
- Constraint
- Context
- Context boundary
- Context diagram
- Context model
- Control flow
- Correctness
- Cross-functional team
- Customer
- Customer requirements specification
- Daily Scrum
- Data flow
- Data flow diagram
- Data flow model
- Decision table
- Defect
- Definition of Done
- Definition of Ready
- Design
- Development team
- Document template
- Domain
- Domain model
- Domain requirement
- Effectiveness
- Efficiency
- Elaboration
- Elicitation
- End user
- Entity
- Entity-relationship diagram
- Entity-relationship model
- Epic
- Error
- Evolutionary prototype
- Exploratory prototype
- Fault
- Fault tolerance
- Feasibility
- Feature
- Feature diagram
- Feature model
- Form template
- Functional requirement
- Functionality
- Glossary (Definition)
- Goal
- Goal model
- Homonym
- Implementation
- Increment (in Software)
- Inspect & adapt
- Inspection
- Item
- Iteration
- Kind of requirement
- Language
- Maintainability
- Method
- Methodology
- Minimal Marketable Product (MMP)
- Minimal Viable Product (MVP)
- Mock-up
- Model
- Modeling language
- Multiplicity
- Native prototype
- Natural language
- Necessity
- Non-functional requirement
- Object
- Object diagram
- Object model
- Performance requirement
- Persona
- Phrase template
- Planning Poker
- Portability
- Potentially releasable product increment
- Practice
- Prioritization
- Priority
- Problem
- Process
- Process model
- Process pattern
- Product (in Software)
- Product Backlog
- Product line
- Product Owner
- Prototype
- Prototyping
- Quality
- Quality requirement
- Redundancy
- Refactoring
- Reference story
- Refinement
- Release
- Reliability
- Requirement
- Requirements analysis
- Requirements baseline
- Requirements branching
- Requirements configuration
- Requirements document
- Requirements elicitation
- Requirements Engineer
- Requirements Engineering
- Requirements management
- Requirements model
- Requirements negotation
- Requirements source
- Requirements specification
- Requirements template
- Review
- Risk
- Roadmap (in agile)
- Role
- Safety
- Scenario
- Scope
- Scrum
- Scrum Master
- Security
- Semantics
- Semi-formal
- Sequence diagram
- Service
- Software requirements specification
- Source
- Specification
- Specification by example
- Specification language
- Spike
- Sprint
- Sprint Backlog
- Stakeholder
- Stakeholder requirement
- Standard
- State machine
- State machine diagram
- Statechart
- State-transition diagram
- Steering committee
- Story
- Story map
- Storyboard
- Structured analysis
- Supplier
- Synonym
- Syntax
- System
- System boundary
- System context
- System requirement
- System Requirements Specification
- T-approach
- Task
- Technique
- Theme
- Timebox
- Tool
- Traceability
- T-Shirt Sizing
- UML
- Unambiguity
- Understandability
- Upfront
- Usability
- Use case
- Use case diagram
- Use case model
- User
- User requirement
- User Story
- Validation
- Variability
- Variant
- Variation point
- Velocity (in agile)
- Verifiability
- Verification
- Version
- View
- Viewpoint
- Vision
- Walkthrough
- Wireframe
- Work product
User