1.2 Supporting References For information relating to the Company Hardware Request project, see the SharePoint web site.

Transcription

1 Hardware Request System Visin 1 Intrductin 1.1 Dcument Purpse and Scpe This dcument utlines the visin fr the Hardware Request system. The purpses f this dcument are t: Identify and agree n the prblems faced by end users and the effects f thse prblems n prductivity and efficiency Gather and describe custmer requests fr sftware features Prpse a slutin (new develpment r alternative) Identify any cnstraints t the prpsed slutin Identify stakehlders and users Identify the sftware develpment team The scpe f the dcument is limited t the crdinatin and facilitatin f Hardware requests between custmers and the Cmpany. 1.2 Supprting References Fr infrmatin relating t the Cmpany Hardware Request prject, see the SharePint web site. 2 Prblem Statement The prblem f N standard frm exists fr dcumenting Hardware requests N guidelines exist fr gathering crrect Hardware requirements in requests N central lcatin exists fr submitting requests fr Hardware N standard tl exists fr dcumenting and tracking requests fr Hardware N guidelines fr minimum Hardware request lead times N feedback lp t persn wh riginally requested Hardware Affects Hardware department Planning department causing the impact f Inefficient recrding and tracking f Hardware requests A successful slutin wuld A prcess that enables users t: prvide Submit Hardware requests frm a web brwser Recrd Hardware requests: Special Hardware requirements Standard Hardware requirements Rute requests frm requestr t apprpriate Lead by Prduct ID Prvide accurate Hardware delivery dates 1

2 Hardware Request System Visin Prvide accurate Hardware delivery quantities Track Hardware requests t validate status f request and request delivery infrmatin Feedback lp t riginal requestr Order executin Validate that Hardware met riginal standard and special requirements Run reprts frm infrmatin in the system 3 Prduct Features 3.1 Ability t Submit Requests Using Web Brwser Web-based system must be accessible t the Cmpany and t the custmers, where all Hardware requests can be submitted. 3.2 Ability t Recrd Request Infrmatin Recrd Standard Hardware Request Infrmatin Users want t recrd basic infrmatin abut the Hardware request, including, but nt limited, t the fllwing: Date and Time f Hardware request submissin (date and time stamp f when the request was submitted) Owner f Request (Username f Planner) Planner wh wns the Hardware request and is respnsible fr cmmunicating with the custmer Hardware Request ID This is a unique number f the request and may be autmatically generated Prduct ID Quantity f Hardware Items Requested Availability Date Pririty Status Custmer Accunt Infrmatin, including: Custmer Name Custmer Business Custmer Address Custmer Phne Custmer Recrd Special Requirements fr Hardware Requests Users want t recrd special Hardware requirements. Users need the ability t list each special requirement when Hardware request are submitted by custmers. 2

3 Hardware Request System Visin Recrd Cmments and Justificatin Users want t recrd cmments abut the Hardware Request and t prvide justificatin infrmatin fr particular requirements r dates prvided. 3.3 Ability t Track Hardware Requests Assign Hardware Request Status Part f the tracking prcess invlves the ability t maintain the status f a request. Examples f Hardware Request Statuses include the fllwing: Submitted Custmer submits Hardware Request. Assigned Lead Planner assigns Planner t Request. Pending Planner accepts the Hardware Request. Under Review Planner cmpletes initial review f Hardware Request t validate that the request is reasnable and acknwledges the Hardware Request. This Review state must be cmpleted within 48 hurs f the Submissin r the Request is autmatically mved t the state f Escalated. Escalated When a Hardware Request remains in the status Under Review fr mre than 48 hurs, the Hardware Request is autmatically assigned the status Escalated, and the Planners receive a ntificatin that they need t review the Hardware request. Reviewed Planning cmpletes the initial review f the Hardware request and determines that the Hardware Request is reasnable and the requirements can be met. Rejected Planning rejects the Hardware Request because the requirements cannt be met by Planning. Apprved Planning apprves the request and determines that the Hardware Request is reasnable. Upn apprval, Lead Planners are ntified f the apprval s they can cmmunicate with the custmer that the Hardware Request requirements can be met. Cmpleted Planning delivers the Hardware and ships the Hardware t the custmer. Clsed Planning will clse the request when he r she has ensured that the custmer received the Hardware and that they were satisfied Assign Hardware Request Pririty Tracking als invlves the prcess f designating a pririty f a request. Examples f Hardware Request Pririties include the fllwing: Lw Medium High Critical 3

4 Hardware Request System Visin Assign Hardware Request Versin Users want t assign a versin number t a Hardware Request t recrd the submissin f a Hardware Request and t track changes made t a Hardware Request. When a change has been made t the Hardware Request, a new versin f that Hardware Request will be created and captured in the system s that users can view the different versins f a Hardware Request and see the prgress f that Hardware Request. In additin, users can revert t a previus versin f a Hardware Request, if needed. Examples f the versining numbers include the fllwing: Create Hardware Request Versin 1.0 Planner Apprves Hardware Availability Dates r Quantities Versin 1.2 Planning Changes Date r Quantity Requirements Versin 1.3 Planning cmpletes Request Versin 1.4 Planning clses Request Versin Escalate Hardware Request Users want the ability t escalate a Hardware Request if particular actins d nt ccur within the defined timeframe f the prcess. 3.4 Ability t Rute Requests Users want t define the wrkflw f the prcess, and then cnfigure the system s that the system autmatically rutes requests by Prduct ID t the crrect wner f a particular step f the request prcess. 3.5 Ability t Ntify Users f Hardware Request Actins Users want the ability t ntify users f the system when particular actins ccur during the Hardware Request prcess. Fr example, when Planners submit a Hardware Request, they want t ntify Lead Planners. In additin, ntificatins might ccur when the status r pririty f a Hardware Request changes r when changes have been made t the Special Requirements r t the quantity r delivery date f the Hardware requests. 3.6 Ability t Define Access Security Users want t determine wh has access t perfrm certain tasks within the system. Fr example, sme users may be able t view and edit requests, and sme users may nly be able t run reprts frm the system. 3.7 Ability t Run Reprts Users want t run canned and ad-hc reprts using infrmatin recrded in the system. The fllwing canned reprts need t be available: By Prduct ID By Hardware Request Status By Hardware Request Owner By Ttal Number f Hardware Requests By Hardware Request Submit Date Range 4

5 Hardware Request System Visin 3.8 Ability t Exprt Data Users want the ability t exprt data frm the system t ther systems. Fr example, users may want t exprt data t Excel r t a reprting tl. Users als want the ability t send system data t ther users in . 4 Cnstraints 4.1 Design Cnstraints System-Supprted Platfrms The system will be develped using platfrm tls and languages supprted by the cmpany, including: VB6 ASP.net MS SQL Server database System must be multi-platfrm and supprt Windws, Linux, and UNIX standard brwsers Expse Features as Services Where pssible, the system will be designed in such a way that its features can be expsed as services Use Existing Services and Data Where pssible, the system will use existing services and data Brwser Cmpatibility System shuld be web-based. 5 Risks 5.1 Risk List Pssible risks t the success f implementatin include, but are nt limited t: Lack f sftware develpment supprt Unclear gals f the system Nn-user-friendly system New requirements added; end-users insist n new requirements Changing baseline requirements; requirements have been baselined, but cntinue t change 6 Stakehlder and User Descriptins 6.1 Stakehlders Name Represents Prject Rle Jhn De Hardware Department Custmer Prject Lead, 5

6 Hardware Request System Visin Name Represents Prject Rle Requirements Specificatin, Develpment Jane De Planning Requirement Specificatin, Develpment 6.2 Users Title Rle Descriptin f Use Hardware Department Super-user f system Experienced users f system Leads Experienced users reviewing Hardware requests Prviding Hardware Delivery Dates and Quantities Planners Super-user f system Experienced users f system Reviewing Hardware Requests 7 Prject Team Members Resurce Prject Rle Respnsibilities Area Represented Jhn De Prject Spnsr Prvides management level supprt and directin t the prject Hardware Department Jane De Custmer Prject Manager Wrking Grup Member Sftware Engineer, Prject Technical Lead Manages custmer related-prject activities Planner Define and priritize planning requirements Sftware Develp and maintain the verall Prject Plan, Iteratin Activity Schedule, and Iteratin Plans. Design and develp system BPA Business Develp and maintain Prcess Analyst business prcess definitin: system Visin, business use-cases, system use cases, and test cases DBA DBA Prvide data services supprt Planning Planning Sftware Sftware Sftware 6