Final Report Requirements
From the use cases described previously, as well as the discussions during incubator meetings, a number of requirements have emerged. The set of requirements in this document should not be viewed as a final set of requirements for a standard decision representation format, but rather as exemplifying the need and usefulness of such a format in the first place.
The requirements can be classified in two broad categories, which can be compared to the classes of functional and non-functional requirements as used in software engineering. The functional requirements express things that should be possible to do with the format, e.g. to aggregate or retrieve certain information, make calculations etc., while the non-functional requirements express general characteristics of the format, e.g. modularity, ease of use etc.
The functional requirements are divided into high-level requirements (HLR), and supporting Competency Questions [ref] that express particular information the format should be able to store and provide to applications and users exploiting it.
HLR 1: The format should be able to record basic information about decisions, such as what the decision was about, what information it was based on, what were the options, who made the decision etc.
Related CQs :
1. Who made a certain decision? Who was involved in making this decision? 2. What was decided, i.e. what was the outcome of the decision? 3. What were the alternatives (options) that were considered? 4. What criteria/constraints/goals/aims influenced the selection of this alternative (option)? 5. What were the predicted consequences of each of the alternatives (options) that were taken into account? 5. What are the sub-decisions of this decision, i.e. the set of alternatives that this overall selected alternative can be broken down into? 6. What action does this alternative imply? 7. Why was this decision made, i.e. what was the original problem (question) that needed to be answered?
HLR 2: The format should be able to support the assessment of efficiency of a decision process through describing time-aspects of a decision process.
Related CQs :
1. When did a certain decision process begin and end? 2. How much time was spent on a certain step of the decision making process? 3. How much time was spent on preparing the decision for communication to others? 4. How much time expired between making the decision and communicating it to the intended audience? 5. How much time was spent on communicating the decision to the intended audience? 5. How much time was spent in a certain step of the decision making process compared to other steps? 6. How much time was spent "waiting" versus time spent processing the decision? 7. What's the average amount of time spent making certain decisions?
HLR 3: The format should be able to support users to assess improvement in decision making from changes in organizational structure or tools designed to improve information flow.
Related CQs :
1. How much time was spent on a certain step of the decision making process, compared to before the change occurred? 2. Was the time spent "waiting" versus time spent processing the decision reduced since the change occurred? 3. Was the average amount of time spent making certain decisions reduced?
HLR 4: The format should be able to support users to track individual information flow in the form of decision flow and time to process decisions across an organization, to measure capability and efficiency of innovation.
1. How much time do I spend on certain decisions compared to others in the organization? 2. How does my average time to complete certain steps compare to the organization as a whole? 3. What is the average amount of time spent making certain decisions in this organization? 3. What decisions were most efficient in this organization?
HLR 5: The format should provide the possibility to align a decision with some available set of data/information, e.g. open linked data.
1. What data sets are supporting this decision? 2. Which components/elements of those data sets are being used as options? 3. Which components/elements of those data sets are being used as criteria/restrictions/constraints to asses the predicted outcome of the options? 4. What is the assessment method/algorithm/query which supports the assessment of the options using the criteria? 5. What is the weighting of the criteria/restrictions/constraints?
HLR 6: The format should effectively represent the metrics used to evaluate the options, including the weighting and thresholds given to those metrics by the decision-makers.
1. What will be (are/were) the metrics for automatically execute this decision? 2. What are the weights given to the metrics? 3. What are the thresholds for determining which options to consider? 4. Is this metric to be minimized or maximized? 5. How will these metrics be combined to generate an overall score for each option?
HLR 7: To support the representation of the current operational picture of some operation or organization, along with anticipated actions of operational individuals driven from operational data.
1. What are the current decisions being considered within this context (e.g. operation or organization)? 2. What are the recent decisions that were made within this context? 3. What are the consequences of this decision? 4. What is the expected next steps (actions) to be taken by this individual/organization/agent based on recent decisions? 5. How will these decisions affect the current context?
HLR 8: To support the representation of the status of the organization through the capture and analysis of its decisions.
1. What is the current state of this organization? 2. What are the recent decisions that were made within this organization? 3. What are the consequences of this decision on the current state of the organization?
Non-functional requirements include requirements on the understandability, reusability and means of using the format.
- The format should be easy to understand by different user groups, such as web developers and decision makers in organizations.
- The format should be modular, in the sense that reusing it should not imply having to reuse all aspects of the decision representation, rather just reusing the part/components that expresses elements relevant to particular needs.
- The format should be expressed based on web standards, such as XML, RDF and OWL, in order to be easily exchangeable and interpreted by applications on the web.
- The format should provide different levels of expressivity, e.g. ranging from a simple XML format to an OWL ontology, so that users can choose the level of expressivity that is needed in a specific case.