Learning one new thing everyday
A UML use case diagram is the primary form of system/software requirements for a new software program under developed. Use cases specify the expected behavior (what) of a system, and not the exact method of making it happen (how). A complete set of use cases specifies all the different ways to use the system and therefore defines all behavior required of the system bounding the scope of the system.
Continue reading
A use case is a written description of how a user performs a task on your system. It outlines the behavior of the system from the user’s perspective when responding to a request. Each use case is represented as a sequence of simple steps, starting with the user’s goal and ending when the goal is achieved.
Continue reading
Use Case 2.0 is a scalable and agile approach that uses use cases to capturing requirements and driving the incremental development of a system to fulfill them. It helps you understand how the system will be used and leading you through the development of an appropriate system to support the users.
Continue reading
A use case diagram models different types of users interact with the system to solve a problem. As such, it describes the goals of the users, the interactions between the users and the system, and the required behavior of the system in satisfying these goals. Use cases define interactions between external actors and the system to attain particular goals. A use case diagram contains four main components
Continue reading
In the summer of 2011, Ken Schwaber and Jeff Sutherland revised their Scrum Guide. In it, they removed one long established behavior known to Scrum, which is the commitment the team makes to the product owner and the customers. Commitment was replaced by forecast. They say that teams may forecast their work, but not commit to it.
Continue reading
Definition of Done (DoD) is a list of requirements that a user story must adhere to for the team to call it complete. While the Acceptance Criteria of a User Story consist of set of Test Scenarios that are to be met to confirm that the software is working as expected.
Continue reading
Each sprint ends with a two-part sprint review meeting. Such a meeting starts with a customer review and demonstration and ends with the team retrospective. Both of these components occur on the last day of the sprint. The Sprint Review focuses on the “inspect” and “adapt” of the increment (Potentially shippable), while the Sprint Retrospective give more focus on the “inspect” and “adapt” of the process of the sprint.
Continue reading
The Open Group created ArchiMate as an open and independent modelling language for enterprise architecture (EA). The standard provides a notation to enable enterprise architects to describe, analyze, and visualize the relationships among business domains in an unambiguous way. ArchiMate enables the creation of fully integrated models of the organization’s EA, the motivation for it, and the programs, projects and migration paths to implement it.
Continue reading
The INVEST as a reminder of the characteristics of a good quality Product Backlog Item (PBI) (or user stories) commonly written in user story format. But what are characteristics of a good user story? The acronym “INVEST” can remind you that good stories should be
Continue reading
If you’ve ever tried to create MS’s Visio Flowchart®, you know how hard it is. You can start with a few basic tools, if you need to change anything — move shapes, delete shapes or add new shapes — it’s too hard! You know what I mean. Visual Paradigm Online automates all your complex tasks with just a few clicks.
Continue reading