Business Driven Technology Study Set 5

Business

Quiz 17 :

Developing Software to Streamline Operations

Quiz 17 :

Developing Software to Streamline Operations

Question Type
search
arrow
The number one reason projects fail is bad business requirements. Business requirements are considered "bad" because of ambiguity or insufficient involvement of end users during analysis and design. A requirement is unambiguous if it has the same interpretation for all parties. Different interpretations by different participants will usually result in unmet expectations. Here is an example of an ambiguous requirement and an example of an unambiguous requirement: Ambiguous requirement: The financial report must show profits in local and U.S. currencies. Unambiguous requirement: The financial report must show profits in local and U.S. currencies using the exchange rate printed in The Wall Street Journal for the last business day of the period being reported. Ambiguity is impossible to prevent completely because it is introduced into requirements in natural ways. For example: Requirements can contain technical implications that are obvious to the IT developers but not to the customers. Requirements can contain business implications that are obvious to the customer but not to the IT developers. Requirements may contain everyday words whose meanings are "obvious" to everyone, yet different for everyone. Requirements are reflections of detailed explanations that may have included multiple events, multiple perspectives, verbal rephrasing, emotion, iterative refinement, selective emphasis, and body language-none of which are captured in the written statements. Tips for Reviewing Business Requirements When reviewing business requirements always look for the following words to help dramatically reduce ambiguity: "And" and "or" have well-defined meanings and ought to be completely unambiguous, yet they are often understood only informally and interpreted inconsistently. For example, consider the statement "The alarm must ring if button T is pressed and if button F is pressed." This statement may be intended to mean that to ring the alarm, both buttons must be pressed or it may be intended to mean that either one can be pressed. A statement like this should never appear in a requirement because the potential for misinterpretation is too great. A preferable approach is to be very explicit, for example, "The alarm must ring if both buttons T and F are pressed simultaneously. The alarm should not ring in any other circumstance." "Always" might really mean "most of the time," in which case it should be made more explicit. For example, the statement "We always run reports A and B together" could be challenged with "In other words, there is never any circumstance where you would run A without B and B without A " If you build a system with an "always" requirement, then you are actually building the system to never run report A without report B. If a user suddenly wants report B without report A, you will need to make significant system changes. "Never" might mean "rarely," in which case it should be made more explicit. For example, the statement "We never run reports A and B in the same month" could be challenged with, "So that means that if I see that A has been run, I can be absolutely certain that no one will want to run B." Again, if you build a system that supports a "never" requirement then the system users can never perform that requirement. For example, the system would never allow a user to run reports A and B in the same month, no matter what the circumstances. Boundary conditions are statements about the line between true and false and do and do not. These statements may or may not be meant to include end points. For example, "We want to use method X when there are up to 10 pages, but method Y otherwise." If you were building this system, would you include page 10 in method X or in method Y The answer to this question will vary causing an ambiguous business requirement. Research the web and determine other reasons for "bad" business requirements.
Free
Not Answered

There is no answer for this question

Tags
Choose question tag
close menu
arrow
Which phase in the systems development life cycle is the most critical when building a social networking website
Free
Essay
Answer:

Answer:

The most critical phase of the development life cycle for building a social networking website is the maintenance phase. During this phase, the social network will grow, develop, attract users, and evolve based on what users prefer. It is in this phase, that the success of the social network will be decided.

Tags
Choose question tag
close menu
arrow
Which phase in the systems development life cycle is the least critical when building a social networking website
Free
Essay
Answer:

Answer:

The least critical phase of the development life cycle for building a social networking website is the testing phase. The planning and analysis phases are critical to prevent costly mistakes that could ruin the site further down its life cycle. The later phases will determine whether the website will grow and take root as a viable social network, or simply be ignored. However, mistakes made during the testing phase can be corrected, albeit with greater effort, during the later phases. These mistakes will not be anywhere near as costly as mistakes made during the planning phase, but they will nevertheless be correctable as user expectations for new social networks tend be rather low. In short, minor bugs that are not dealt with during the testing phase can always be fixed during the maintenance phase.

Tags
Choose question tag
close menu
arrow
The number one reason projects fail is bad business requirements. Business requirements are considered "bad" because of ambiguity or insufficient involvement of end users during analysis and design. A requirement is unambiguous if it has the same interpretation for all parties. Different interpretations by different participants will usually result in unmet expectations. Here is an example of an ambiguous requirement and an example of an unambiguous requirement: Ambiguous requirement: The financial report must show profits in local and U.S. currencies. Unambiguous requirement: The financial report must show profits in local and U.S. currencies using the exchange rate printed in The Wall Street Journal for the last business day of the period being reported. Ambiguity is impossible to prevent completely because it is introduced into requirements in natural ways. For example: Requirements can contain technical implications that are obvious to the IT developers but not to the customers. Requirements can contain business implications that are obvious to the customer but not to the IT developers. Requirements may contain everyday words whose meanings are "obvious" to everyone, yet different for everyone. Requirements are reflections of detailed explanations that may have included multiple events, multiple perspectives, verbal rephrasing, emotion, iterative refinement, selective emphasis, and body language-none of which are captured in the written statements. Tips for Reviewing Business Requirements When reviewing business requirements always look for the following words to help dramatically reduce ambiguity: "And" and "or" have well-defined meanings and ought to be completely unambiguous, yet they are often understood only informally and interpreted inconsistently. For example, consider the statement "The alarm must ring if button T is pressed and if button F is pressed." This statement may be intended to mean that to ring the alarm, both buttons must be pressed or it may be intended to mean that either one can be pressed. A statement like this should never appear in a requirement because the potential for misinterpretation is too great. A preferable approach is to be very explicit, for example, "The alarm must ring if both buttons T and F are pressed simultaneously. The alarm should not ring in any other circumstance." "Always" might really mean "most of the time," in which case it should be made more explicit. For example, the statement "We always run reports A and B together" could be challenged with "In other words, there is never any circumstance where you would run A without B and B without A " If you build a system with an "always" requirement, then you are actually building the system to never run report A without report B. If a user suddenly wants report B without report A, you will need to make significant system changes. "Never" might mean "rarely," in which case it should be made more explicit. For example, the statement "We never run reports A and B in the same month" could be challenged with, "So that means that if I see that A has been run, I can be absolutely certain that no one will want to run B." Again, if you build a system that supports a "never" requirement then the system users can never perform that requirement. For example, the system would never allow a user to run reports A and B in the same month, no matter what the circumstances. Boundary conditions are statements about the line between true and false and do and do not. These statements may or may not be meant to include end points. For example, "We want to use method X when there are up to 10 pages, but method Y otherwise." If you were building this system, would you include page 10 in method X or in method Y The answer to this question will vary causing an ambiguous business requirement. Why are ambiguous business requirements the leading cause of system development failures
Essay
Answer:
Tags
Choose question tag
close menu
arrow
Why is the cost of finding errors important to a business when developing software
Essay
Answer:
Tags
Choose question tag
close menu
arrow
The number one reason projects fail is bad business requirements. Business requirements are considered "bad" because of ambiguity or insufficient involvement of end users during analysis and design. A requirement is unambiguous if it has the same interpretation for all parties. Different interpretations by different participants will usually result in unmet expectations. Here is an example of an ambiguous requirement and an example of an unambiguous requirement: Ambiguous requirement: The financial report must show profits in local and U.S. currencies. Unambiguous requirement: The financial report must show profits in local and U.S. currencies using the exchange rate printed in The Wall Street Journal for the last business day of the period being reported. Ambiguity is impossible to prevent completely because it is introduced into requirements in natural ways. For example: Requirements can contain technical implications that are obvious to the IT developers but not to the customers. Requirements can contain business implications that are obvious to the customer but not to the IT developers. Requirements may contain everyday words whose meanings are "obvious" to everyone, yet different for everyone. Requirements are reflections of detailed explanations that may have included multiple events, multiple perspectives, verbal rephrasing, emotion, iterative refinement, selective emphasis, and body language-none of which are captured in the written statements. Tips for Reviewing Business Requirements When reviewing business requirements always look for the following words to help dramatically reduce ambiguity: "And" and "or" have well-defined meanings and ought to be completely unambiguous, yet they are often understood only informally and interpreted inconsistently. For example, consider the statement "The alarm must ring if button T is pressed and if button F is pressed." This statement may be intended to mean that to ring the alarm, both buttons must be pressed or it may be intended to mean that either one can be pressed. A statement like this should never appear in a requirement because the potential for misinterpretation is too great. A preferable approach is to be very explicit, for example, "The alarm must ring if both buttons T and F are pressed simultaneously. The alarm should not ring in any other circumstance." "Always" might really mean "most of the time," in which case it should be made more explicit. For example, the statement "We always run reports A and B together" could be challenged with "In other words, there is never any circumstance where you would run A without B and B without A " If you build a system with an "always" requirement, then you are actually building the system to never run report A without report B. If a user suddenly wants report B without report A, you will need to make significant system changes. "Never" might mean "rarely," in which case it should be made more explicit. For example, the statement "We never run reports A and B in the same month" could be challenged with, "So that means that if I see that A has been run, I can be absolutely certain that no one will want to run B." Again, if you build a system that supports a "never" requirement then the system users can never perform that requirement. For example, the system would never allow a user to run reports A and B in the same month, no matter what the circumstances. Boundary conditions are statements about the line between true and false and do and do not. These statements may or may not be meant to include end points. For example, "We want to use method X when there are up to 10 pages, but method Y otherwise." If you were building this system, would you include page 10 in method X or in method Y The answer to this question will vary causing an ambiguous business requirement. What is wrong with the following business requirement: "The system must support employee birthdays since every employee always has a birthday every year."
Essay
Answer:
Tags
Choose question tag
close menu
arrow
The number one reason projects fail is bad business requirements. Business requirements are considered "bad" because of ambiguity or insufficient involvement of end users during analysis and design. A requirement is unambiguous if it has the same interpretation for all parties. Different interpretations by different participants will usually result in unmet expectations. Here is an example of an ambiguous requirement and an example of an unambiguous requirement: Ambiguous requirement: The financial report must show profits in local and U.S. currencies. Unambiguous requirement: The financial report must show profits in local and U.S. currencies using the exchange rate printed in The Wall Street Journal for the last business day of the period being reported. Ambiguity is impossible to prevent completely because it is introduced into requirements in natural ways. For example: Requirements can contain technical implications that are obvious to the IT developers but not to the customers. Requirements can contain business implications that are obvious to the customer but not to the IT developers. Requirements may contain everyday words whose meanings are "obvious" to everyone, yet different for everyone. Requirements are reflections of detailed explanations that may have included multiple events, multiple perspectives, verbal rephrasing, emotion, iterative refinement, selective emphasis, and body language-none of which are captured in the written statements. Tips for Reviewing Business Requirements When reviewing business requirements always look for the following words to help dramatically reduce ambiguity: "And" and "or" have well-defined meanings and ought to be completely unambiguous, yet they are often understood only informally and interpreted inconsistently. For example, consider the statement "The alarm must ring if button T is pressed and if button F is pressed." This statement may be intended to mean that to ring the alarm, both buttons must be pressed or it may be intended to mean that either one can be pressed. A statement like this should never appear in a requirement because the potential for misinterpretation is too great. A preferable approach is to be very explicit, for example, "The alarm must ring if both buttons T and F are pressed simultaneously. The alarm should not ring in any other circumstance." "Always" might really mean "most of the time," in which case it should be made more explicit. For example, the statement "We always run reports A and B together" could be challenged with "In other words, there is never any circumstance where you would run A without B and B without A " If you build a system with an "always" requirement, then you are actually building the system to never run report A without report B. If a user suddenly wants report B without report A, you will need to make significant system changes. "Never" might mean "rarely," in which case it should be made more explicit. For example, the statement "We never run reports A and B in the same month" could be challenged with, "So that means that if I see that A has been run, I can be absolutely certain that no one will want to run B." Again, if you build a system that supports a "never" requirement then the system users can never perform that requirement. For example, the system would never allow a user to run reports A and B in the same month, no matter what the circumstances. Boundary conditions are statements about the line between true and false and do and do not. These statements may or may not be meant to include end points. For example, "We want to use method X when there are up to 10 pages, but method Y otherwise." If you were building this system, would you include page 10 in method X or in method Y The answer to this question will vary causing an ambiguous business requirement. Why do the words and and or tend to lead to ambiguous requirements
Essay
Answer:
Tags
Choose question tag
close menu