Considered the most complex aspect of the project. Output of this phase form critical inputs to determine project schedules, budgets, resourcing, implementation / upgrade / development methodologies and testing strategies. Errors introduced in this stage are costly to fix in later stages of the project lifecycle. Slide 4 Market research shows … Challenges It is difficult to articulate and envision what is needed Users do not clearly understand what they want or need
Multiple stakeholders take time to freeze on business requirements Bridging the gap between requirements understood between domain experts and product specialists or technical personnel Focusing and influencing solutions to the business need rather than defining the need Changes in requirements after scope and budgets are fixed Analysis Paralysis Slide 6 What happens if you don’t get requirements right? Consequences of not beginning right Expensive rework and cost overruns A poor quality product Late delivery Dissatisfied customers Exhausted and demoralized team members
Begin right to finish right !! Cost of fixing defects escalates as the project progresses ! Phase Relative cost of defect fix Requirements x Design 3 – 6x Coding 10x Testing 15 – 40x After go-live 40 – 1000x Slide 8 Requirements Basics Requirement Definition A well-formed requirement as a statement that States a customer’s business problem – achieves stated objectives States system functionality – must be met or possessed by the system Can be validated Is qualified by measurable conditions and bounded by constraints Slide 10 Characteristics of a good requirement
The Term Paper on Project Cost And Schedule
1. (TCO B) Estimating Procedures (a) You are the project manager for a new high-rise office building. You are working on estimating the exterior landscaping for the new development. The landscaping requires the use of a special landscape stone. Based on recent experience the most likely price for the material is $120.00/ton. However, the price for this stone is volatile, and the price fluctuates ...
Must be achievable within realistic or definable budgets Must be verifiable, avoid defining by words such as excessive, sufficient, reasonable Must be unambiguous – have one possible meaning Must be expressed in terms of need, not solution Must be consistent with other requirements and conflicts resolved Must be documented and expressed in a language understandable to every one Slide 11 Example: Housing Project Level1: Need a Place to Stay. Your Need Level2: Detail Functional Requirement Detail System Requirement (1) Build or Rent. (2) Number of Bed Rooms. (3) Car garage
(4) Kitchen. (5) Flooring. (6) Basement (7) Kids Room (8) Location (9) Square Feet (10) Pricing Level3: What builders need to do to build? Key requirement categories Level1: Why the project is being undertaken? Business Req User Requirement System Requirement Level2:What the users will be able to do with the product? Level3: What developers need to build? Less Detail Business Requirement Business focus User Requirement User Focus External Business Internal Technical Hardware Requirements More Detail System Requirement Operating sys Requirements System focus Software
Requirements Network Requirements requirement gathering Requirement gathering steps Solicit requirements from sources. Raw requirements Well formed requirements. Identified functions Elicitation Requirements are documented unambiguously and completely Analysis Specification Vali dation examines the requirements to ensure that they satisfy user’s needs V alidation Next Phase Defining and capturing good requirements is a joint effort Criteria for who needs to be involved Who uses the system? Who trains people to use the system? Who develops, fixes and maintains the system?
Who starts up the system, who shuts it down? Who creates, updates, deletes information in the system? What other systems interface with the system? Who gets information from this system? Who provides information to the system? Requirement gathering methods interviews Workshops Focus Groups brainstorming Survey Product Demos questionnaire Techniques to trigger thoughts: List of Q uestions: Prepare a list of questions ahead of time to use as a general guide for the session. U se cases describe the system from the point of view of the user using the system.
The Term Paper on Information Systems in Business
List of the databases in which data about you exists •Flat- file data bases. The flat file databases are used to store small amounts of data that is required to be edited by the hand. They are made up of files strings that combine one or more files and they are effective in storing simple data lists but they become complex if the data structures are replicated. Flat file databases require a simple ...
They are an easy format for all people to quickly grasp the system’s functionality. E xisting System – When working with an existing system, use it to trigger ideas quickly. Have the user walk through how they do the task now in the system. W hiteboard – Always use a whiteboard to sketch out ideas. Capture use cases, sketch out user interfaces or draw process flows on the whiteboard. Screen Mockups – For applications with user interfaces, start with mockups of the UI. Wire frames are simple black and white boxes and text, Use paper, PowerPoint, or a whiteboard to draw theUIs.
Requirements Gathering tips Choose the right requirements gathering technique depending on the context Identify business sponsors, approvers and get buy-in on plans Ensure stakeholders are identified for the each set of requirements Publish schedules and plans for requirements sessions early Identify each requirement with a unique id – traceability to functional designs, technical designs, test scenarios is important Ensure business analysts and end users speak and document requirements in the same language Key players in ERP requirement gathering Business Owners PeopleSoft Business users
PeopleSoft Business Analyst PeopleSoft Technical / Development Team PeopleSoft Technical / Systems Team PeopleSoft Project Manager PeopleSoft Technical Writers Requirements Analysis requirement analysis takes elicited information and tries to make sense of it Less Detail Business Requirement Business focus User Requirement User Focus External Business Internal Technical Hardware Requirements More Detail System Requirement Operating sys Requirements System focus Software Requirements Network Requirements Key to the requirement analysis Organize. Prioritize. Compartmentalize. Correlate.
Requirements Documentation A well documented requirement specifications are very critical to the project. They ensure that all gaps in the design do not exist and test coverage is significantly improved. Language of requirements It is the same language everyone can understand – an Eighth Grader should be able to understand Avoid terminology interpretation issues by including a glossary of terms and definitions in the requirements document If the language is consistent, it greatly lowers the risk of misinterpretation of the requirements. Writing requirement document for multiple audience
The Essay on Database Abss System Document
ABSTRACT The Automated Business Service System (ABSS) was designed for the military to process documents without wasting an enormous amount of time. The original way of processing a document involved typing the document up and visiting each person to sign off on it. Not only was this time consuming but there was no historical record available if the original document was lost or destroyed. ABSS ...
Business requirement documentation (BRD) User or functional documentation (USD or FSD) System requirement documentation (SRD) These documents have different purpose and are used by different parties on the software project. Depending on the project there may even be different sets of documents required within the company Document Should Have Business Justification Assumptions Constraints Impact Analysis Solution Options Cost and Time Estimates Functions Accomplished Use Scenarios Test Cases • By keeping it simply you encourage participation and thus increase the chances of
effective collaboration. By keeping the document you encourage participation, invoke thoughts and thus increase the chances of effective collaboration and a complete requirement. Requirements Gathering for a PeopleSoft ERP upgrade Requirements Gathering For PeopleSoft ERP upgrades. Compile all the documentation prior to project start. Understand current customization levels. Assign a requirement leader for each module. Prepare questionnaires and responses for each Topic / Module. Use a combination of Workshop, Questionnaire methods for requirement gathering phase.
Review New Functionality through prototyping. Analyze and Prioritize the customizations by complexity (high, medium, low) and criticality (need to have, must have, nice to have) Slide 34 Requirements Gathering during ERP upgrades Conduct walkthroughs of new release processes delivered by Oracle. “K eep – Drop” decisions taken during the workshop. Finalize ‘to-be’ processes for the businesses. Update current documentation or add new documentation. Conversion needs are determined and overall conversion strategy is developed. Testing needs are determined and testing strategy is developed. Slide 35
The Business plan on Organizational Fit Erp Business Companies
INTRODUCTION The assignment will explore ERP from its origin and would shed light on its fundamentals and implementation procedures. ERP will be evaluated from two perspectives of two different companies which implemented the ERP solution. First we will be discussing! SS Cisco! |s!" ERP implementation and the technical and business issues related to that and then we will move on to the other case ...
