Actors: Individuals, groups, organizations, systems and even other business processes that perform functional or operational activities contributing to the completion of a specific process. They act within the context of processes and influence the delivery and success of specific services, systems and operations the organization manages. Many actors will be described functionally (program manager), while also having a personal identity (Jill Smith).
Business Owner (BO): The person responsible for the business case for the service or system.
Business Requirement: what the needed achievements will be for a service or system, and the quality measures in order to preform some operational aspect of the organization. These are usually expressed in terms of broad outcomes the business requires, rather than specific functions the system may perform. These are not technical or functional, rather are specific to business processes. Note that the business requirements often can be broken up into sub-business requirements and many functional requirements.
Dupe: When someone requested more than one program in the same campus (Marketing). Can also be short for "duplicate", meaning more than one.
Functional Requirements: Descriptions of what the service or system must do in order to fulfill the business requirements. Note that the business requirements often are broken up into sub-business requirements and thus many functional requirements.
Gap: The difference in any current functionality or performance available within a supported service or system (operating in accordance to the defined service level agreement) and an expressed functional or technical need defined by a stakeholder for that same service or system.
Information Flow: The what, why, how, when, etc. for the collection, distribution, consumption and archiving of information as it affects a process and thus service or system. Information flow represents the various exchanges and activities between processes and actors, and other entities.
Issue: Any service or system currently in production that is not operating in accordance to the defined service level agreement.
Process: One or more activities undertaken by actors required to deliver a service or system.
Product: Any service or system supported by the UMOL Technology Team.
Product Owner (PO): The person responsible for defining and confirming functional requirements for a service or system.
Project: Any requested service or system not currently supported by the UMOL Technology Team.
Repository: "Locations" in which objects are stored specific to a service, system or process. (Also know as: "Content Repositories")
Requirements Gathering: See Functional Requirements Gathering or Technical (Non-Functional) Requirements Gathering
Retrospective: Retrospectives play a crucial role in Agile teams. They are the time specifically put aside to reflect on how the team is performing and what can be done to improve. "... a meeting held by a project team at the end of a project or process (often after a certain number of iterations) to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects." - Wikipedia
The process of retrospecting is at the heart of many Agile practices: Scrum (Inspect and Adapt), Extreme Programming (fix it when it breaks) and Lean Software Development (Kaizen or Continuous Improvement)
Scrum Master: The person responsible for facilitating productivity in the Scrum method of agile software development.
Service: Any activity that supports a specific or set of business functions. Online Learning and Data Reporting are examples of "services" currently supported by UMassOnline. Also, see "Systems."
Storytelling: A Storytelling Exercise is part of the requirements gathering process where actual end-users (see "actors") describe how they are working within or with a specific service or system. The goal of storytelling is to understand the current working environment, roles of the actors involved, and how the service or system aligns with current business process and operations. The results of this exercise should include non-technical information, emphasizing the language of the end-users and the associated functional units. A convenient construct for storytelling is, "As a [insert actor] I want to [insert desire], so that I can [insert outcome]. Story telling differs from user stories in that storytelling defines current functionality, while user stories define desired functionality. Both differ from use cases in that they are less detailed.
- Also see: "User Story" and "Use Cases."
System: Any technology or set of technologies that support a specific service. Blackboard Vista and Cognos are examples of systems that support the services of online learning and data reporting respectively. Also see "services."
Technical Owner (TO): The person responsible for the administration of the service or system
Technical Requirement: The various technological infrastructure, as well as the skill sets of users (including the operational environment), that a service or system will operate within.
Use Case: A use case is a description of a service or system’s behavior as it responds to a request that originates from outside of that service or system. In other words, a use case describes "who" can do "what" with the service or system in question. The use case technique is used to capture a service or system's behavioral requirements by detailing scenario-driven threads through the functional requirements.
- Also see "Story-telling" and "User Stories."
- Requirements 101: User Stories vs. Use Cases
User Story: (http://en.wikipedia.org/wiki/User_story ) A user story is a service or system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used for the specification of new (as apposed to existing features: see story-telling) requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card--usually a 3×5 inches card--to ensure that it does not grow too large. The user stories should be written by the customers and are their main instrument to influence the development of a service or system. A convenient construct for deriving a user story is, "As a [insert actor] I want to [insert desire], so that I can [insert outcome]. User stories differs from storytelling in that user stories define future functionality, while storytelling define current functionality. Both differ from use cases in that they are less detailed.
- Also see "Story-telling" and "Use Cases."
- Introduction to User Stories
- Requirements 101: User Stories vs. Use Cases
Value Flow: See "Information Flow" above.
This page has no comments.