Avans 1.x Concepts

Notations

SMART

A good learning goal is concrete, realistic and helps you to work on your skills in a focused way. Use the following steps and tips to formulate the learning goal.

To make your learning goals clear and achievable, we use the SMART method. SMART stands for Specific, Measurable, Acceptable, Realistic and Time-bound.

1. Specific: Make sure that your goal is concrete and describe exactly what you want to improve.

   • Example: Instead of “better communicating,” you formulate: “I want to communicate more clearly by asking for feedback after each presentation.”

2. Measurable: Your goal must be measurable, so that you can determine when you have achieved it.

   • Example: Add a measurable aspect, such as “I want to ask for feedback from the client at least once per project.”

3. Acceptable: The goal must be achievable for you within this project and this period. Consider what you can achieve with a reasonable effort.

   • Example: Choose goals that you really want to improve and that fit the available timeframe.
   • Or: Choose skills that you still want to improve further, for example because that fits well with your role as… evaluator, scrum master, discussion leader etc.

4. Realistic: Formulate a goal that fits within your education and the required skills. Aim for improvement, but do not make the goal too ambitious.

   • Example: “I want to collaborate better” becomes more realistic by saying: “I want to actively listen during every team meeting and contribute at least once.”

5. Time-bound: Specify within which period you want to achieve the goal. This helps to evaluate your progress.

   • Example: “Within the next six weeks, I want to receive feedback on my contribution at every team meeting.”

STARR

A well-structured narrative using the STARR method is detailed and contextual, ensuring you cover all relevant aspects of an experience or requirement. STARR stands for Situation, Task, Action, Result and Reflection. Here’s how to apply it:

1. Situation:
   Describe the context or background. Explain where and when the event or requirement took place.

   • Example: “During a critical project phase, our team encountered communication gaps.”

2. Task:
   Define the task or challenge that needed to be addressed. Outline what was expected or required.

   • Example: “I was responsible for ensuring that all team members were aligned with the project goals.”

3. Action:
   Outline the specific actions you took to address the task. Detail the steps or measures implemented.

   • Example: “I organized daily stand-up meetings and introduced a shared project tracker.”

4. Result:
   Explain the outcomes of your actions. Describe what changed, including any measurable improvements or achievements.

   • Example: “The team’s communication improved significantly, reducing misunderstandings and increasing project efficiency by 20%.”

5. Reflection:
   Reflect on the experience. Discuss lessons learned, what could be improved, and how the experience informs future actions.

   • Example: “I learned that proactive communication can prevent issues and that regular feedback sessions are essential for continuous improvement.”

MOSCOW

MOSCOW is a prioritization technique used in project management and software development to categorize requirements or features. It stands for Must have, Should have, Could have and Won’t have. This method helps in clarifying priorities and aligning expectations:

6. Must have:
   These are the essential requirements or features without which the project would fail. They are non-negotiable.

   • Example: “User authentication must be implemented to ensure system security.”

7. Should have:
   Important features that add significant value but are not critical for the initial release. They can be postponed if necessary.

   • Example: “The system should have a reporting dashboard for monitoring performance metrics.”

8. Could have:
   Desirable features that enhance user experience or add extra value but are not essential. These are often considered if time and resources allow.

   • Example: “The application could have a dark mode to improve usability in low-light environments.”

9. Won’t have:
   Requirements or features that have been agreed to be out of scope for the current phase or release. These are deferred for future consideration.

   • Example: “Integration with third-party services won’t be implemented in the current version.”

Requirements

User Story Format

• who, what, why
• add acceptance criteria to it
• add context
• common practice in software development
• it never describes the solution

as administrator I want to be able to see who all has an account because I want to be able to adjust who has access.

If the why part is logical, you may omit it, otherwise you get redundancy:

• as user I want to be able to log in to be logged in

Acceptance Criteria

• it must be measurable, well defined
• specific
• concrete
• testable / reproducible by someone else

This is attached to a user story.
For the user story: as user I want to be able to log in, you can attach the requirements:

• Password input field
• Username validation
• Error messages that do not tell whether the user exists or not.

or something like this

case diagram

abstract representation of how a system should work.

Pseudocode