Học một điều mới mỗi ngày
A decision table is an excellent tool to use in both testing and requirements management. Essentially it is a structured exercise to formulate requirements when dealing with complex business rules. In a decision table, business logic is well divided into conditions, actions (decisions) and rules for representing the various components that form the business logic.
Continue reading
We always come across these terms in software development. Sometimes people a piece of software feature — requirement/ use case, backlog items …. What is the convention of the software people for using that or which?
Continue reading
In software development , the usual “estimation” includes a quantitative evaluation of the work required to perform a given development task; this is usually expressed in terms of duration (hour / day) or estimated unit (story point). The purpose is to consolidate a number of such individual estimates in order to obtain an indication of the overall duration, work or cost of the software project.
Continue reading
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