[Original link] System Architect (Second Edition) study notes ---- Requirements Engineering
Article directory
1. Requirement definition
1.1 Contents included in the requirements
- The conditions or abilities required by users to solve problems or achieve goals
- A system or system component must meet the conditions or capabilities required by a contract, standard, specification, or other formally defined document.
- A documented description that reflects the conditions or capabilities described above
1.2 3 different levels of software requirements
- Business needs
- User needs
- Functional Requirements
1.3 Stages of requirements engineering
- Requirements acquisition
- demand analysis
- formulate requirements specifications
- Requirements confirmation and verification
- Demand management
1.4 Main contents of demand management
- Control changes to the demand baseline
- Keep project plans consistent with requirements
- Control the version status of individual requirements and requirements documents
- Manage requirements and link chains, or manage dependencies between individual requirements and deliverables from other project departments
- Track requirements status in baselines
2. Requirement acquisition
2.1 Basic steps for requirement acquisition
- Develop high-level business models
- Define project scope and high-level requirements
- Identify user roles and user representatives
- Get specific needs
- Determine the business workflow of the target system
- Requirements sorting and summary
2.2 Requirement acquisition method
- User interviews
- Requirements Symposium
- Questionnaire
- On-site observation
- prototyping method
- Brainstorming
2.3 Participants in the requirements discussion meeting
- host
- user
- Technical staff
- Project team members
2.4 Advantages of symposia
- Assist in building a high-performing team around project success goals
- All stakeholders speak freely
- Facilitate consensus between stakeholders and development teams
- Uncover and resolve administrative issues that hinder project success
- Ability to quickly produce preliminary system definitions
- Can effectively resolve conflicting requirements for primary keys of different stakeholders
3. Changes in requirements
3.1 Requirements change management process
- Problem analysis and change description
- Change analysis and costing
- Change implementation
3.2 Requirement change strategy
- All requirements changes must follow the change control process
- Design and implementation work should not be done for unapproved changes
- Changes should be decided by the Project Change Control Board which changes should be implemented
- Project stakeholders should be able to understand the changes
- The original document of the change request must never be deleted or modified from the project configuration repository
- Each integrated requirement change must be traceable to an approved change request to maintain horizontal traceability
3.3 Composition of the Change Control Board (CCB)
- Product or Program Management
- project management department
- development department
- Testing or Quality Assurance Department
- Marketing or Account Representative
- Department that produces user documentation
- Technical support department
- Help desk or user support hotline department
- Configuration management department
3.4 CCB operation steps
- Specify decision
- communication situation
- renegotiate the agreement
3.5 Two methods of demand tracking
- forward tracking
- reverse tracking