Podstawy inżynierii wymagań i analizy ( piwa | 14 hours )

Training goal

Training participants will acquire basic skills, useful for immediate application in practice, in the field of requirements engineering, business analysis and system analysis, both its organizational and technical aspects.

target group

Analysts (business analysts and system analysts) and requirements engineers who want to systematize their knowledge and skills and acquire new ones, and all people who need the skills to effectively acquire, analyze and manage changes in user and business requirements: programmers, project managers, testers, participants scrum teams, as well as people ordering software who need to skillfully communicate their needs to IT departments or external suppliers.

Block 1: Requirements without requirements engineering – good and bad practices

• Workshop 1 – where do the requirements actually come from?
• Requirements engineering or business analysis?
• Requirements engineering hidden in project management
• Agile, i.e. truly excellent requirements engineering (although hidden under exotic terminology)
• Requirements engineering is the responsibility of the programming team
• Quality will be the cost of lack of requirements engineering

Block 2: How precise should the requirements be?

• Workshop 2 – what determines the accuracy of a cookbook?
• Requirements thoroughness as a function of failure consequences
• Requirements accuracy as a function of product size and complexity
• Requirements thoroughness as a function of organizational characteristics

Block 3: Good and bad requirements

• Features (properties) of good requirements
• Useful requirements parameters and their possible values
• Good requirements as elements of the product backlog in agile

Block 4: Methods of obtaining requirements

• Workshop 3 – searching for requirements
• Business vision and requirements for the IT system
• Stakeholders: us, them and others
• The system boundary, the system context, and the rest of the world
• Requirements elicitation process
• Requirements elicitation techniques
• Validation and negotiation of requirements

Block 5: describing requirements

• Exploratory requirements definition
• Description of requirements in natural language – benefits and threats, auxiliary methods
• Requirements modeling
  •  Light use of incomplete modeling
  •  User stories
  •  Control flow diagrams
  •  Swim lane diagrams
  •  Data flow diagrams (contextual)
  •  Entity relationship diagrams
  •  UML: use case diagrams
  •  UML: activity diagrams
  •  UML: state transition diagrams
  •  UML: interaction diagrams
  •  UML: structural diagrams
• Requirement descriptions: formats, templates, documents or tools (ReQtest, DOORS, other tools)

Block 6: Requirements and what next?

• Estimating workload based on requirements
• Linking requirements to the system vision, to each other, to the system architecture, components, and to tests
• How to deal with changes in requirements