王廷瑋|數位醫療|智慧醫療: Requirements Definition WFU

2024年6月30日 星期日

Requirements Definition

Questions & Communication Channels


  • When people communicate, there are three channels that send information to someone.
    • verbal channel: what you say or what you write if the communication is in written form
    • paraverbal channel: consists of how you say what you say in terms of word emphasis, tone of voice, and pacing
    • nonverbal channel: body language
  • One way is to be on the lookout for when the three channels are not in synch with each other.
  • Risk associated with getting correct and complete requirements information


Ask better question


  • In fact, 55 percent is sent in the nonverbal channel, 38 percent in the paraverbal, and only 7 percent in the verbal channel.
  • Open-ended questions: most powerful type of question for learning about things
  • Closed-ended questions: useful when you need to get yes/no responses, very specific finite information, and to get agreement.
  • Clarifying questions: you need to confirm your understanding of what someone has told you
  • Probing questions: follow-up and get more information about something, specific examples of something, or when someone has answered a prior question with a generic word like usually, mostly, sometimes, or often leading questions
  • Leading questions
  • Double-barreled questions


Some Tools & Techniques


  • Surveys
  • Brainstorming
    • define the objective of the brainstorm
    • set a time limit for people to think about their input
    • collect input from the group
    • looking through the ideas, maybe combining ideas that are the same but were stated using different words, maybe rewording things to improve clarity, or developing categories that the ideas belong to
    • prioritize or rank the ideas
  • Multi-voting
    • each person in the group to select the most important items on the list
    • tally the votes for each item on the list
    • consists of eliminating the items with the fewest votes
    • repeats until we’ve reduced the list to the desirable size
  • Cause-effect analysis
    • cause-effect diagram


Use Case Components


  • three primary components to a use case:
    • summary fields: contain information like the use case name, use case participants, use case goal, assumptions, and so forth
    • a main success scenario: contains the typical
    • interactions between users, other systems, and the system under development.
    • one or more alternate scenarios: consist of interactions that describe alternate ways to achieve the goal of a use case, as well as interactions required to handle errors
  • An actor is someone or some thing that interacts with the system we are gathering requirements for.
  • actors must be external to the system we are gathering requirements for, and, a use case must have at least one actor
  • Every use case must have a name and the name should give us some idea about the goal of the use case
  • A trigger is an event that causes a use case to start.
  • A pre-condition describes the state of the system that is required before a use case can attempt to start.
  • A post-condition describes the state of the system after a use case has taken place successfully


Main Success & Alternate Scenarios


  • The main success scenario is the first use case scenario that we write
  • When business rules or data elements are associated with an action step, it‘s best to reference them in the action step rather than hard-coding them into the action step.
  • Alternate scenarios are written below the main success scenario.


Using Decision Tables


  • Business rules typically specify how to take a function’s inputs and convert them to the function’s output


Using State Models


  • a state is a set of conditions at some point in time and those conditions can change over the course of time based upon things that occur
  • state transition matrix


Data Models


  • a conceptual data model: describes things, called
  • entities, that will be stored, and the relationships
  • between those entities
  • a logical data model: elaborates on a conceptual data model by including attributes associated with the entities
  • a physical data model: describes how the product’s database will actually be built
  • data model:
    • an organized representation of business data that will need to be stored and managed
    • The benefit of using a data model is that it provides more precise, detailed, and unambiguous information about the data that will need to be stored and managed.
  • discover the types of data that will need to be managed and stored
  • study the associations or relationships that some of these entity types will have with respect to each other
  • Technically, a model that shows the entity types and their relationships is called a conceptual data model.
  • Entity types must have attributes. Attributes correspond to information that will be stored and managed.
  • When attributes are added to the conceptual model it’s technically called a logical data model.
  • Another step in data modeling, that is usually performed in the later stages, is to “normalize” the logical data model
  • Associations represent relationships that entity types have with one another.
  • Data normalization is a technique that is used to organize data into tables.
  • When you normalize a database, you have four goals:
    • arranging data into logical groupings such that each group describes a small part of the whole;
    • minimizing the amount of duplicate data stored in a database;
    • organizing the data such that, when you modify it, you make the change in only one place;
    • building a database in which you can access and manipulate the data quickly and efficiently without compromising the integrity of the data in storage.


Business Process Models


  • process hierarchy diagram, process decomposition diagram
  • UML Activity Diagram
  • swim lane diagram
  • context diagram
  • data flow diagram
  • create, read, update, and delete matrix