240 likes | 477 Views
Organizational approaches to requirements. Colin Potts Georgia Tech. The role of systems in organizations. An organization is the context for the system’s functions Organization provides rationale for system Some theoretical perspectives on organizations view them as systems
E N D
Organizational approaches to requirements Colin Potts Georgia Tech
The role of systems in organizations • An organization is the context for the system’s functions • Organization provides rationale for system • Some theoretical perspectives on organizations view them as systems • Sociotechnical systems theory • IS design is mixture of Human Activity System (HAS) redesign & technical design HAS1 HAS2 IS
Soft Systems Methodology (SSM) A methodology for understanding a HAS and stating recommendations for change Not specific to IS Analysis of HAS “pushes” change Origins in STS action research Business Process Reengineering (BPR) Philosophy of HAS improvement; not a single methodology HAS is a collection of controllable processes Technology may “pull” HAS redesign Origins in Quality-Improvement movement practice Overview: SSM & BPR
Soft systems methodology • Collection (not rigid sequence) of interlinked analysis activities Implementation Problem situation unstructured Feasible/ desirable changes Outward-directed (“real-world”) activities Real-world/ system comparison Problem situation expressed Conceptual models Inward-directed (“systems”) activities Root definitions
Rich pictures • A sketch illustrating the current situation
CATWOE: stakeholder types • The HAS is described in terms of six key attributes: C = Client/customer (Who are beneficiaries of HAS?) A = Actors (Who perform activities within the HAS?) T = Transformation (What does the HAS do?) W = Weltanschauung / worldview (What are the key assumptions behind the HAS?) O = Owner (Who owns the HAS and can cause it to cease?) E = Environment (What constraints exist on how the HAS works?)
CATWOE Example:Meeting scheduling • C: Senior mgt. & office workers • A: Office workers & admin. assts. • T: Satisfy time utilization for teamwork • W: Busy people; coordination a pain • O: Senior mgt. / IS dept. • E: Calendar; corporate values
Writing a root definition • Textual definition of HAS working in CATWOE attributes: A system, owned by senior management and the IS department, operated by office workers and administrative assistants to utilize their time effectively for teamwork within the constraints of the calendar and corporate values.
Conceptual modeling in SSM • Model what is “systemically desirable” • Informal flow diagram calendar indiv. working prefs. identify prefs negotiate schedule monitor & control time call mtg make resources available need to meet resource constraints
Levels in SSM • Each subsystem of the conceptual model may be decomposed as a HAS
Comparing the model with the world • Does the systemically desirable HAS correspond to the real-world HAS? • E.g. is conceptual model consistent with rich picture? • obviously not a formal analysis process • If not, where can improvements be made? • SSM does not have methods for reaching consensus on change • and what should an IS do to improve HAS?
Team Exercise: “Quick-and-dirty” SSM • For the example system: • As a class: (1) discuss the HAS context • In teams of 2-3: (2) Draw a rich picture (3) Discuss & write root definition for HAS (4) Draw a conceptual model (top level) (5) Identify v. high-level IS requirements • As a class: (6) Discuss what you produce
SSM: How to find out more • Several books. • Checkland & Scholes: Soft Systems Methodology in Action • Classic, but not specific to IS • Patching: Practical Soft Systems Analysis • More of an action guide • Stowell & West: Client-Led Design • Specific to IS, but not strictly SSM
Business process reengineering (BPR) • Basic thesis: an organization operates through a series of processes • Repeatable activities, roles, procedures & rules • Processes can be modeled, supported & “enacted” • HAS is improved by redesigning processes Local optimization Radical redesign (e.g. TQM) (e.g. BPR) Scope of improvement
The role of IS in BPR • Needs “pull” vs. technology “push” Process “How” identify how IS can support process “What” Candidate processes possible IS “Where” “How” potential technology select processes that technology can support
Organizational use cases • Use case = standard interaction between system and its environment • For an organizational use case, the system is a HAS, envt. is the business envt. • Dual models (same concepts used) • “is”: how things are done • “ought”: envisioned improvement
member of public Example use cases for library circulation .... membership mgt. publisher librarian stock mgt.
member of public Example object model • E.g. borrowing a book customer service assistant borrowing policy book library patron
Cust. Svc. asst. Borrowing policy Patron Book Member of public presents books Customer service assistant checks membership card Borrowing policy checks that member of public is library patron in good standing Customer service assistant records books to be borrowed Borrowing policy updates book record Customer service assistant tells borrower due date Interaction diagrams
Envisioning new processes • Consider possible use cases in an IS-supported HAS • Use analogies • Standard optimizations • For example • How is a library like a gas station? • Borrowing stations like gas pumps? • Remove assistant by having unattended check-out station
Team exercise: BPR use cases • For the standard example: • as a class: (1) Decide on a single business process • in groups of 2-3: (2) Identify & categorize objects for process (3) Draw an interaction diagram (4) Envision new system & describe to class
BPR: How to find out more • Several books • Hammer & Champy: Reengineering the Corporation • Morris & Brandon: Reengineering your Business • Johansson et al: Business Process Reengineering • Jacobson et al: The Object Advantage
Organizational methods: conclusion • Basic goal • Understand the context • Only then determine whether a system is necessary, and if so where its boundary should be • Preconditions • Sense that something’s wrong or that an opportunity beckons • No clear technical problem yet apparent