Popular in Course
verified elite notetaker
Popular in Department
This 6 page Study Guide was uploaded by Experthelper Notetaker on Friday November 6, 2015. The Study Guide belongs to a course at a university taught by a professor in Fall. Since its upload, it has received 23 views.
Reviews for BSA_400_Wk3_DesignPhase
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 11/06/15
Once consultants and stakeholders mutually decide upon an adequate software suite for their particular organization, the development team must begin what is known as the design phase of an enterpriselevel implementation project. During this stage of development, analysts will focus on translating the client’s system requirements into customized software configurations, built upon the information gleaned during requirements elicitation. Ideal configurations can be collectively achieved through the use of prototyping, which can assist in the confirmation of user requirements, and by adopting an effective design methodology; one which overcomes the inevitable shortcomings found in traditional “waterfall” models. Also crucial during the design phase is the analyst’s clear distinction between functional and non functional requirements, thus enabling them to discern system qualities from system functions. 1. Prototyping (5 Points). Explain how prototyping tools could be used to confirm requirements. Software prototyping is a technique that allows a development team to test the functionality of certain aspects of a system through the use of simulations, constructed to represent specific portions of an enterprise package before actual implementation occurs. Prototypes are essentially models of the software interfaces that users will eventually encounter, and are based upon the initial requirements that were established during the analysis phase of development. These simulations offer developers valuable information about what will and will not work when it comes to software configurations, since users are actively involved throughout the prototyping process. According to Beaudouin Lafon and Mackay (2003), two basic forms of software prototypes exist: offline and online. Offline prototypes are generally employed during the early stages of an ERP implementation, and can include tools such as “paper sketches, illustrated storyboards, cardboard mockups and videos” (Beaudouin Lafon and Mackay, 2003, p. 12). Although these may seem like rudimentary implements, offline prototypes have the advantage of being far less expensive than their online counterparts, and require little or no technical expertise to use. If an analyst wanted to determine whether an organization’s accounting department felt comfortable with a proposed menu layout, for instance, he could simply draw the imagined user screen on an easel and invite feedback from a conference roomfull of users. This method allows a development team to communicate their interpretations of previously elicited user requirements, in a simple, inexpensive illustration that can easily be modified or disposed of when a concept doesn’t work. Online prototypes, on the other hand, used later in the design process; consist of working software modules that possess varying levels of functionality and fidelity (the prototype’s level of detail and resemblance to the final product). Four main online prototyping strategies are available during latter stages of the ERP project, including horizontal, vertical, taskoriented, and scenariobased approaches (Beaudouin Lafon and Mackay, 2003). Both horizontal and vertical prototypes are generally used by larger software development teams, the former consisting of a wide range of features with minimal functionality (helping users understand feature relationships) and the latter comprised of a narrow set of features that are almost completely functional (simplifying poorly understood system features). Taskoriented prototypes are designed to walk a user through a series of steps necessary to complete individual, job specific tasks within a system. One example might include an HR module in which all functions needed to process employee paychecks are present, enabling a user from that department to see how each menu and level relate to one another and ultimately function. Scenariobased prototypes are similar to the previous example, except that in this approach, design emphasis is placed on modelling realworld scenarios, which help gauge user reactions to simulated events. Although the last two prototyping methods offer more detailed feedback than vertical or horizontal techniques, they are also expensive and time consuming. As a result, either method is generally used only when absolutely necessary. It is important to remember that each prototyping tool can be beneficial to ERP development, but only when used appropriately. Online techniques can be costly and tedious, so it is crucial for an analyst to properly align their prototyping approach with the firm’s chosen ERP design methodology. 2. Design method (5 points). Describe which design method you prefer for developing an enterpriselevel information system. Because enterprise software development cycles are such massive, complex operations, various implementation methodologies have been gradually developed to help make the software adoption process more efficient. Probably the best known and most traditional approach to software development is known as the “waterfall” model; a linearsequential process which is divided up into six or eight individual work phases (depending on the variation), each of which must be completed before the project can advance to the next step. Recently, however, several organizations have chosen to take a more flexible approach to ERP projects, adopting hybrid versions of Agile methodology. Agile methods emphasize open lines of communication between users, stakeholders, and developers throughout the ERP process, and are generally more adaptable than traditional waterfall models. Jason Fair (2012), illustrates the inefficiency of traditional methods, stating: “During a waterfall project typically less than 30% of effort is devoted to building the product. The remaining 70% is spent on peripheral activities, management and administration” (para. 1). Instead of using rigid, lengthy work phases, Agile development is iterative; comprised of shorter timeblocks (usually lasting about 14 days), each producing a predetermined piece of the overall software package. This form of project management allows the team to employ evolutionary prototyping techniques, which enable them to continuously adapt the software to meet a client’s everchanging set of requirements. As each module or subsystem is delivered, users are invited to interact with the software, inevitably testing its functionality in the process. Once developers have elicited feedback from the test group, configurations and features can be reconfigured before final deployment. The cyclical nature of Agile development makes it leaner, faster, and more productive than most traditional approaches, making it the method of choice for a growing number of ERP project consultants around the world. 3. Functional/nonfunctional (5 points). Identify the differences between functional and nonfunctional requirements. Often, the differences between functional and nonfunctional software requirements are poorly understood by a project’s participants. This is a crucial distinction to make for all involved in an ERP implementation, as these requirements will eventually shape the configuration of the endproduct. A functional requirement specifies something a system should do, while a nonfunctional requirement essentially specifies how a system should behave ("ReQtest", 2014). To put those definitions into perspective, consider a hypothetical invoicing module within an enterprise system. An example of a functional requirement would be: “Print specified invoice numbers on default invoice_printer 1 when CTRLP is input by the user.” Conversely, a nonfunctional requirement in the same system might be: “Must not print more than 50 invoices per user request.” It is important to remember that nonfunctional requirements form the system’s constraints, drawing boundary lines around each functional requirement. Failure to clearly define each requirement, be they functional or nonfunctional, can result in costly reconfigurations towards the end of the project. To avoid this pitfall, analysts and consultants must be willing to spend an adequate amount of time on the task of grouping and defining user requirements during the initial phases of ERP development. Enterpriselevel software deployments are costly, intricate, and often frustrating projects that should only be attempted by experienced teams, using the most effective methods for the task at hand. The use of offline and online prototyping techniques is one way for developers to connect with users during that process. Prototypes engage users and offer visual approximations of the ERP, setting the stage for analysts to confirm or deny initial requirements during the design phase. Agile methodology is an ideal fit for the use of prototypes, with its core principles centered on incremental production. By offering up individual software modules at the end of each time block, the development team gradually builds the configurations around user/stakeholder feedback; all while being mindful of the crucial difference between functional and nonfunctional requirements. These combined techniques are proven to produce quality results in any ERP development environment. References Beaudouin Lafon, M., & Mackay, W. (2003). The humancomputer interaction handbook . Hillsdale, NJ: L. Erlbaum Associates Inc.. Fair, J. (2012). Project Management Institute. Retrieved from http://pmi fr.org/index.php?option=com_content&view=article&id=610:agilevswaterfallwhatapproach isrightformyerpprojectbyjasonfair&catid=80:congrespmiglobal&Itemid=152 ReQtest. (2014). Retrieved from http://reqtest.com/requirementsblog/functionalvsnon functionalrequirements/
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'