• Home

business system analysis

---

---

All About IT Analysis
A blog about Business Analysis, Systems Analysis, Data Analysis, Games Analysis, and everything in between.

• Use Case - Documenting a Form / Page
  Don’t use a Use Case to Document a Form or a PageYou may have encountered some use cases describing a page or a form with each and every button having different goals explained in ghastly detail. I can only presume that this is the remnant of former methodologies carried forward inside the use case.Good News! You do not have to do so! Do not use a use case template to describe a form or a web page. The intent of a use case is to describe a set of interactions to
• Referencing Steps - Part 2
  Trick of the Trade to avoid Administrative NightmareBy now, you should be familiar with the fact that the use case flow of events often references the basic flow.When you construct your use case, you will find that it's much easier to use the MS-Word Cross-reference feature to reference the steps in your flow of events. When you do, it means than any update you make to the sequencing (the numbering) or the name of the step is automatically updated whenever it is u
• Report Requests
  Where do you Document Request for Online Reports?Do not use a Use Case template to document a report request. Use a Report Request template designed for that purpose.That being said, though, if part of your application involves a feature where a user can go to a page and selects to run a report, then that constitutes a use case. For report requirements, however use the appropriate template, and include a reference in the Special Requirements section.ExampleA
• Documentation \ System Interfaces
  Where should you document System Interfaces?
• Documenting Business Rules
  Documenting Business Rules Business rules are a kind of requirement. Unfortunately, there is no precise definition for a business rule - it may mean different things to different people. Sequence of ActionsIn some cases, a business rule refers to a sequence of events the system must provide (e.g. you can only send a letter after you have confirmed that the address is not a PHI address.) These are expressed as steps in a use case. V
• Use Case \ Documentation
  Use Case Independence A use case is considered ‘a good use case’ when it provides something of significant value to at least one actor. It should satisfy a goal of one of the actors - something that, if it were the only thing the system did, would still provide value to at least one of its stakeholders. Note that this applies only to concrete use cases, not to those that extend other use cases (extension use cases) or included by other use cases (included use case
• Referencing Steps in a Use Case
  In the Basic Flow, you should never reference an Alternate Flow or a Special Requirement – it should be the opposite way around – The Alternate Flow or Special Requirements should reference the Basic Flow. This article shows how to do it.
• Documentation \ System Features
  Vision documents can be difficult to write. Actually, many Analysts have a hard time writing a good and succint vision document. The Airport Coffee Bar analogy can help keep the vision document at the business level.
• Use Case \ Documentation \ Copy & Paste
  Beware of Copy and Paste Hmm! Copy and Paste! Great, right? Well, not so fast for a Use CaseWe all rave about the ability to Copy and Paste. It makes many of our daily tasks much easier. However, when writing Use Cases, using this beloved function should be a red flag that your use case is not properly modeled.Not only does it make your use case more difficult to read, but it also creates an administrative burden to maintain, and can create requirements
• Documentation \ Security Grid
  Documenting the Security Grid? Make sure to include the security grid in the supplementary specification. Describe the inter-level use case security in the Supplementary Specification document; but intra-level use case security should be described in the special requirements section within the use case.Do I need a Security Grid?You have probably created dozens of inter-level Security Grids. That’s system-wide security. Well, good news! If
• Use Case \ Start & End
  Use Case Start & EndThis is crucial for the Flow of EventsMake sure you specify where a use case starts and ends. There is only one starting point, but there can be several ending points. The starting point should be during Step 1 of the Basic Flow. Make sure the first steps reads: “The use case starts when…”The start of a Use Case is triggered by an action from the primary actor. You should write that action. I often see: “The actor wishes to do …�
• Vision Document \ The Problem Statement
  How Specific does my Problem Statement have to be?In the Vision document, the Problem Statement is very important when starting a project for an application, a website or a system. If you are having difficulties coming up with a good Problem Statement, that’s because you are most likely targeting a technology-level problem, instead of a business-level problem.In such case, you need to perform further root-cause analysis – this will help you bring the language
• Business Context Diagrams \ Constructing the Business Context Diagram
  The business context diagram is often mistaken for the system context diagram or an interaction diagram, whereby Analysts confuse what the diagram is supposed to represent and the paradigm to go about constructing it.The previous section dismissed the myths most often held by Business & Systems Analysts, while this section discusses how to construct the business context diagram.
• Modeling the Navigation Map
  Many Analysts get dumbfounded in front of a blank page when creating a Navigation Map. Unmistakably, it seems like everyone is able to read navigational maps, but their construction is not so evident.
• Business Context Diagrams \ Myths \ Myth # 8
  It is not true that Regulatory Stakeholders should be included on the Business Context Diagram.