掌握需求過程(下)

共讀.jpg

第十章 功能需求

功能需求指明了產(chǎn)品必須做的事情序矩,即產(chǎn)品為了滿足它存在的根本需求和根本理由,而必須執(zhí)行的一些動作啃擦。
需要功能需求,是因為當業(yè)務分析是理解了產(chǎn)品必須的功能后珠叔,他要用功能需求告訴開發(fā)者要構(gòu)建什么姥芥。
如果利益相關(guān)者對產(chǎn)品用例場景達成一致,業(yè)務分析師寫下一組功能需求台囱,確定該場景表明的功能簿训,接下來開發(fā)者利用這些需求來構(gòu)建產(chǎn)品。


圖片發(fā)自簡書App

1 細節(jié)程度或力度

需求是由一個單句寫成米间,只有一個動詞强品。
注意產(chǎn)品“應該”的形式,他使用了主動句车伞,并關(guān)注于溝通產(chǎn)品打算做的事情择懂。
也為開發(fā)者和其他利益相關(guān)者提供了一致的形式另玖,這些人需要清楚地理解產(chǎn)品打算做什么。

2 描述和理由

需求不止包含描述表伦,你需要在需求中添加理由谦去,說明需求為什么存在。
在某些情況下蹦哼,這可能很明顯鳄哭。
但在許多情況下,這是需求的關(guān)鍵部分纲熏。
加入理由后妆丘,你不僅讓開發(fā)者有機會構(gòu)建最好的解決方案,而且也告訴測試人員局劲,需要在測試這項需求上投入多少工作量勺拣。
很清楚理由表明這項需求值得關(guān)注,對描述給出理由鱼填,需求本身就變得更有用了药有。
也向未來的維護者說明了需求一開始為什么會存在。
理由也有助于克服不小心寫下解決方案,而不是真正的需求愤惰。
很容易通過描述一種實現(xiàn)來隱藏重要的功能苇经,也容易選擇最明顯的實現(xiàn),忽略可能更好地實現(xiàn)宦言。
不論需求最終如何實現(xiàn)寫下描述和理由扇单,顯然會導致發(fā)現(xiàn)真正的需求。

3 數(shù)據(jù)你的秘密武器

只要你開始收集常用的術(shù)語奠旺,就應該在數(shù)據(jù)字典中定義術(shù)語的含義令花。
你列出這些數(shù)據(jù)流的屬性,從而定義他們凉倚,這些屬性又讓你能建立業(yè)務數(shù)據(jù)模型兼都。
這個數(shù)據(jù)模型作為某些功能需求的定義,并為團隊提供了共同的語言稽寒。

4 異常和可選方式

異常是不期望扮碧,但不可避免地對正常情況的偏離。
是由處理的錯誤或不正確的活動引起的杏糙,對于這些需求必須明確的說明慎王,只有當異常發(fā)生時,他們才會成為現(xiàn)實宏侍。
為了做到這一點赖淤,可以標明一些需求與特定的異常有關(guān),或者于每一項需求都包含這個異常條件谅河。

5 有條件的需求

如果需求只有在特定的處理環(huán)境下才會發(fā)生咱旱,就會出現(xiàn)這種情況。

6 避免二義性

不論你的需求來源是書面的文檔還是訪談的口頭描述绷耍,都應該注意大量潛在的二義性和由此帶來的誤解吐限,比如一詞多義。

7 技術(shù)需求

技術(shù)需求是純粹因為所選擇的技術(shù)而需要的功能褂始。
技術(shù)需求不是因為業(yè)務上的理由而存在诸典,而是為了讓選擇的實現(xiàn)方式能工作,將技術(shù)需求放在一份單獨的規(guī)格說明書中記錄下來崎苗。

小婧的總結(jié):

本章對于描述功能需求方面進行了一些講解狐粱。
值得關(guān)注的是第二個部分,關(guān)于“理由”的說明胆数。
我非常贊同與研發(fā)團隊溝通的時候“順便”介紹一下我們?yōu)槭裁匆鲞@樣的需求浅妆。
有的時候研發(fā)團隊在設(shè)計的時候會根據(jù)你這個“順便”提供更好的可擴展的設(shè)計和解決方案沛婴。
但是在這個過程中要警惕“需求鍍金”。


第十一章 非功能需求

非功能需求描述的產(chǎn)品必須具備的品質(zhì)。
換言之新荤,將事情做到什么程度。
這些需求讓產(chǎn)品有吸引力,易用、使用快速酸休、可靠和安全。
需要這些屬性不是因為他們是產(chǎn)品的功能活動祷杈,而是因為客戶希望這些活動以特定的方式執(zhí)行并達到特定的品質(zhì)斑司。

非功能需求并不改變產(chǎn)品的基本功能,也就是說不管增加多少屬性但汞,功能需求都會保持不變宿刮。
更復雜的事,非功能需求可能為產(chǎn)品增加功能私蕾。
功能需求導致產(chǎn)品去完成工作僵缺,非功能需求為工作賦予特征:功能需求是動詞,非功能需求是形容詞踩叭。


圖片發(fā)自簡書App

非功能需求類型:

  • 觀感:產(chǎn)品的外觀精神實質(zhì)
  • 易用性和人性化:產(chǎn)品的用心程度磕潮,以及更好的用戶體驗所需的特征 可用性考慮
  • 執(zhí)行:功能的實現(xiàn)必須多快,多可靠容贝,能完成多少處理量自脯,可用性,多精確
  • 操作:產(chǎn)品的操作環(huán)境斤富,以及對該操作環(huán)境必須考慮的問題
  • 可維護性和支持:預期的改變以及完成改變允許的時間膏潮,也包括對產(chǎn)品的支持的規(guī)定
  • 安全:產(chǎn)品的安全性、私密性满力、可恢復性和可審計性
  • 文化和政策:由產(chǎn)品的操作所涉及的人的文化和習慣所帶來的特殊需求
  • 法律:哪些法律和標準適用于該產(chǎn)品

為了遵從不要寫解決方案的指導原則焕参,請檢查你的需求,如果它包含任何技術(shù)因素或任何方法脚囊,就重寫它龟糕,避免提及任何技術(shù)或方法。
可能需要反復做幾次悔耘,直到達到要求的技術(shù)無關(guān)性,但對最終產(chǎn)品設(shè)計的影響來說我擂,這是值得的衬以。

小婧的小結(jié):

其實非功能需求很多都是和業(yè)務場景以及功能需求相關(guān)的。
我們在考慮非功能需求的時候可以從這些角度出發(fā)校摩。
比如這個場景下會有哪些非功能的要求看峻。
然后站在模塊或者產(chǎn)品的角度去思考諸如安全性、可維護性等方面的非功能性需求衙吩。
而且我個人覺得非功能性需求之間可能也存在權(quán)衡和取舍的問題互妓,比如要考慮數(shù)據(jù)安全性,可能就會損失一些易用性。這個具體要看產(chǎn)品的要求以及客戶的關(guān)注點冯勉。


第十二章 驗收標準和理由

我們這里所說的驗收意味著:解決方案完全滿足或符合需求澈蚌。也就是說,解決方案準確的實現(xiàn)了需求所要求做的事情灼狰,或具備需求所要求的屬性宛瞄,不多也不少。
需求本身必須是可測量的交胚,需求的測量指標就是驗收標準份汗。
它煉化了需求的行為執(zhí)行方式以及一些其他的品質(zhì)。
想準確的了解需求蝴簇,必須以某種方式對描述進行量化杯活。
一旦測量需求,也就是用數(shù)字來表述熬词,誤解的可能性就很小了旁钧。

1 驗收需要標準的原因

如果產(chǎn)品有一項需求,要執(zhí)行某個功能或具備某種屬性荡澎,那么測試活動必須展示產(chǎn)品確實執(zhí)行了該項功能均践,或具備了該項期望的屬性。
為了進行這樣的測試需求摩幔,必須有一個測試基準彤委,這樣測試者才能比較提交的產(chǎn)品和最初的需求。
測試基準就是驗收標準或衡,基于需求的量化焦影,它說明了產(chǎn)品必須到達的標準。

2 需求理由的理由

理由就是需求的原因或存在的道理封断。
為需求加上理由斯辰,可以更容易理解真正的需求。
利益相關(guān)者常常會告訴你一個解決方案坡疼,而不是他們真實的需求彬呻。
或者他們會告訴你一向很模糊的需求,以致暫時沒有什么用處柄瑰。理由不僅是幫助你發(fā)現(xiàn)驗收標準的指導闸氮,也幫助你發(fā)現(xiàn)是否有好幾項不同的需求,偽裝成了一項需求教沾。
而且蒲跨,理由也為如何實現(xiàn)需求的決定提供了基礎(chǔ)。

在產(chǎn)品使用和運維人員方面授翻,理由將起到重要的作用或悲。
假定你需要對產(chǎn)品進行變更孙咪,由于不理解理由而導致的問題,也是軟件維護成本非常高的一部分原因巡语。
測試者需要做出最佳決定翎蹈,就需要理解需求的理由。
理由是業(yè)務和提交的產(chǎn)品之間認識的紐帶捌臊。
你必須問為什么杨蛋,不斷的問為什么,知道理解了需求的真正理由理澎。

3 測量的尺度

所有需求都可以測量逞力,你要做的就是找到合適的尺度來測量它。
測量的尺度是用于測試產(chǎn)品符合程度的單位糠爬。
比如對于一個易用性需求寇荧,可以測量學習產(chǎn)品所需的時間,或達到供熱能力水平的時間执隧,或者可能是使用該產(chǎn)品完成工作的差錯率揩抡。
各種品質(zhì)都有測量尺度,你可以測量很多東西镀琉。

4 非功能需求的驗收標準

非功能需求是產(chǎn)品必須具備的品質(zhì)峦嗤,諸如應用性、觀感屋摔、執(zhí)行特點等烁设,因此驗收標準是對這些品質(zhì)進行量化。不要為了需求可測量而放慢需求發(fā)現(xiàn)的過程钓试。
要了解利益相關(guān)者的意圖以及理由装黑,然后分析你的理解,編寫對驗收標準的最佳闡釋弓熏,與利益相關(guān)者討論并改進它們恋谭。
你們必須都同意你建議的驗收標準,準確地測量了這項需求挽鞠。

5 功能需求的驗收標準

功能需求是產(chǎn)品必須做的某件事情疚颊,即產(chǎn)品必須完成的動作。
驗收標準指明了如何得知產(chǎn)品已經(jīng)成功地完成了該動作信认。
對功能需求來說串稀,不存在測量的尺度。
因為動作要么完成狮杨,要么沒完成。
完成就是權(quán)威滿意到忽,因為產(chǎn)品正確地執(zhí)行了該動作橄教。
這里的權(quán)威要么是數(shù)據(jù)源清寇,要么是發(fā)起該行動的相鄰系統(tǒng)。
功能需求的一般原則是:驗收標準確保功能正確的執(zhí)行护蝶。

6 驗收標準的形式

編寫驗收標準华烟,最常見的方式是采用自然語言的文字和數(shù)字。
如果你采用這種方式持灰,就要確保驗收標準中使用的所有數(shù)據(jù)盔夜,在規(guī)格說明書中都有定義,并在需求中一致的使用堤魁。
最好的方式是創(chuàng)建數(shù)據(jù)字典喂链,定義工作范圍內(nèi)的術(shù)語。當然你也可以使用其他圖式驗收標準妥泉。比如椭微,決策表、過程模型狀態(tài)盲链、模型蝇率、決策樹、動態(tài)模型和其他技術(shù)刽沾。
只要能夠以二義性最小的方式表達所需的測量指標本慕,具體方式無所謂。

7 解決方案限制條件的驗收標準

限制條件是一種特殊類型的需求侧漓,他們是全局需求锅尘,通常是管理層預先規(guī)定的。
但他們也需要正確制定火架,像其他類型的需求一樣鉴象,所有其他限制條件,如實現(xiàn)環(huán)境何鸡,伙伴應用纺弊,商業(yè)上架銷售軟件,開源軟件工作場地骡男,環(huán)境時間預算淆游,財務預算都應該有驗收標準。本章小結(jié)
驗收標準既不是測試隔盛,也不是對測試的設(shè)計犹菱,而是測試提交的產(chǎn)品時必須采用的測試基準。
它是構(gòu)建測試用例的輸入信息吮炕,測試者通過測試用例來確保產(chǎn)品的每項需求腊脱。
都符合它的驗收標準,量化或測量需求龙亲,讓你有更好的機會和利益相關(guān)者進行交流陕凹。
為需求加上驗收標準悍抑,鼓勵測試人員參與需求過程。
驗收標準是真正的需求杜耙,驗收標準是用精確方式來陳述的搜骡,可能使用數(shù)字或測量指標來表達它的含義。
驗收標準也是多個利益相關(guān)者之間達成一致的手段佑女,驗收標準通常寫在需求描述之后记靡。

小婧的小結(jié)

需求的驗收標準非常重要,特別是如果你是使用敏捷框架团驱。
一個需求怎么才能算是完成摸吠,這個有很多判定的條件,其中驗收標準是非常重要的一個店茶。
通常我們的驗收標準寫的可能主要是針對功能性的蜕便,因為非功能性的需求不好提,不好驗贩幻。
但是本章作者給我們舉了很多生動的例子轿腺,證明非功能需求也是可以進行量化和測試的,這是很好的啟發(fā)丛楚。但是值得注意的是這些指標數(shù)字要有理可據(jù)族壳,而不是拍腦袋的。
另外針對需求的理由趣些,確實也應該記錄仿荆。
否則不說人員離職將這部分信息帶走了,就個人而言過個一年半載的也不記得當時的理由坏平,這是很正常的拢操。
而記在哪里這件事情我覺得值得商榷。
因為作者是基于“白雪卡”等方式去管理需求的舶替,所以可以在上面進行記錄令境。
我們倒是可以考慮在story或者SRS中增加這么一個條目,專門用來記錄這項需求的理由顾瞪。


第十三章 質(zhì)量關(guān)

需求來自于人舔庶,人們并非總能確定他們需要什么,并非總能解釋他們想要什么陈醒,需求也并非總是編寫的很小心完整無二義性惕橙。
需求工作的要點是,你必須確保交給開發(fā)者的東西是準確的钉跷、完整的弥鹦、成熟的、真正的需求爷辙,任何不足都有違需求工作的初衷惶凝。
開發(fā)者可以構(gòu)建任何東西吼虎,但他們必須首先知道他們必須構(gòu)建什么。
質(zhì)量關(guān)守關(guān)人確認每項需求苍鲜,然后將它們加入需求規(guī)格說明書中。

圖片發(fā)自簡書App

當規(guī)范的潛在需求到達質(zhì)量關(guān)玷犹,是它應該足夠完整混滔、以便進行測試,決定是否納入規(guī)格說明書歹颓。
被拒絕的需求坯屿,退回個體后退回給提出者,要求澄清修改或取消巍扛。

1 需求質(zhì)量

需求規(guī)格說明领跛,是指一項或多項需求的集合。
它可以是你選擇的任何方式撤奸,包括存在在你的頭腦中吠昭。
如果規(guī)格說明是錯的,產(chǎn)品也會錯胧瓜。
質(zhì)量關(guān)測試就是要盡可能的保全保需求的正確性
需求錯誤代價巨大矢棚,如果允許錯誤,經(jīng)過需求過程進入后續(xù)的開發(fā)工作府喳,代價會越來越大蒲肋。
及早的發(fā)現(xiàn)錯誤修正的成本就越來越低。

2 使用質(zhì)量關(guān)

質(zhì)量關(guān)防止不受歡迎的钝满,不想要的需求進入需求規(guī)格兜粘。
需求通過質(zhì)量關(guān)并進入需求規(guī)格說明,必須經(jīng)過一系列測試弯蚜,這些測試確保需求是完整的孔轴、準確的,不會因為不合適將來的設(shè)計和實現(xiàn)而引起麻煩熟吏。

圖片發(fā)自簡書App

3 超出范圍

項目中有一個很常見的問題距糖,就是超出范圍的需求。
我們討論了如何建立上下文范圍牵寺,來確定工作的范圍悍引。
而上下文范圍的另外一種用法,就是作為需求是否超出范圍的仲裁者帽氓。
上下文模型中的數(shù)據(jù)流入或者離開工作領(lǐng)域趣斤。
他們決定了功能,也就是說如果你決定要自動化黎休,某些功能就必須編寫需求浓领。
雖然上下文模型很清楚的說明了范圍玉凯,但你也必須考慮需求的相關(guān)性。
要測試需求的相關(guān)性联贩,就要比較他的意圖和項目的目標漫仆。
測試相當簡單,這項需求對項目的目標作出貢獻嗎泪幌?
這項需求對項目對產(chǎn)品滿足項目目標有直接或間接的幫助嗎盲厌?
需求可能逐漸的對產(chǎn)品作出貢獻,有時候產(chǎn)品的需求需要做一些事情與目標沒有直接的關(guān)系祸泪,但是如果沒有這些需求產(chǎn)品將不能實現(xiàn)他們的目標吗浩。
質(zhì)量關(guān)守關(guān)人可以放行這樣的需求,他們對項目的目標作出了貢獻没隘。
許多非功能性需求也可以看作對象懂扼,目標有間接貢獻。
無關(guān)的需求可能意味著利益相關(guān)者對項目的目標有誤解右蒲,或者意味著新的業(yè)務領(lǐng)域正在打開阀湿。

4 測試完整性

完整性測試指出,每項需求都應具備的相關(guān)屬性品嚣。
如果缺少某些屬性原因要么很明顯炕倘,要么需要解釋。
對需求的每個屬性進行測試翰撑,站在每個利益相關(guān)者的角度問一下罩旋,是否有可能誤解。4 測試驗收標準
質(zhì)量關(guān)守關(guān)人的任務就是要確保驗收標準是合理的需求測量指標眶诈。
即可以對照需求來測試產(chǎn)品涨醋。
第一個要問的問題就是:需求是否有一個正確定義的驗收標準?
如果沒有對它的理解就可能不充分逝撬。
對驗收標準的下一個問題是:是否能作為設(shè)計驗收測試的輸入信息浴骂?
你也應該考慮是否存在經(jīng)濟有效的方法來測試。
實現(xiàn)這項需求的解決方案宪潮,驗收標準也必須符合現(xiàn)實項目的目標溯警。
驗收標準可能是采用事先定義的標準,安全需求也可能會采用標準作為驗收標準狡相。
質(zhì)量關(guān)守關(guān)人應該檢查標準是否適用于這項需求梯轻,驗收標準采用數(shù)字還是用標準,這取決于需求的類型尽棕。
不論哪種情況喳挑,缺乏合適的驗收標準,就足以拒絕這項需求。

依據(jù)使用術(shù)語伊诵,要讓指定的需求只能用一種方式理解单绑,除了驗收標準之外,你還需要在規(guī)格說明書中定義術(shù)語及其含義曹宴,保持一致的第二件事是檢查每項需求使用的數(shù)據(jù)方式都符合定義搂橙,關(guān)于不一致性最后的一點,應該對他有心理準備浙炼,你應該利用質(zhì)量觀來消除它

5 現(xiàn)實條件下是否可行

可行的需求是指這樣一些需求:我們能以經(jīng)濟有效的方式為他們開發(fā)解決方案份氧,并在實施之后能夠成功運營。
你是否具備這項需求的技術(shù)能力弯屈?
你是否有時間和財力來實現(xiàn)這項需求?
是否所有利益相關(guān)者都接受該需求恋拷?
是否存在其他限制條件要求不可行资厉?
是否存在一些伙伴應用或預期的工作環(huán)境與該需求沖突?
是否存在一些解決方案限制條件蔬顾,使得需求難以實現(xiàn)或不可能實現(xiàn)宴偿?

6 需求還是解決方案

很不幸,對需求的描述常常以解決方案形式給出诀豁。
這導致把重點放在一種可能的解決方案上窄刘。
這種方案不一定最合適,通常隱藏的真正的需求舷胜。
方法:

  • 檢查該需求娩践,它是否包含技術(shù)元素,它的編寫方式是否描述了某種過程烹骨?
  • 想想潛在的解決方案翻伺。
  • 如果以一種抽象的方式來編寫需求,其他解決方案都是可能的沮焕。
  • 檢查需求的基礎(chǔ)內(nèi)容吨岭,你必須拒絕所有不是需求的解決方案,除非解決方案實際上是限制條件峦树。

7 需求價值

需求所附的顧客滿意度/不滿意度評分辣辫,說明了顧客對該項需求價值的認識。8 鍍金需求
"鍍金"這個術(shù)語來自鍍金浴室龍頭.
軟件業(yè)用這個術(shù)語來指代那些不必要的特征或需求:他它們對產(chǎn)品成本的貢獻多于對產(chǎn)品功能的貢獻魁巩,它存在也許是因為有了就很不錯急灭,但如果產(chǎn)品不實現(xiàn)該功能,沒有人會介意歪赢。
對鍍金的第一項檢查就是:如果沒有該需求化戳,會有影響嗎?
如果沒有人能真正地提出該需求的正當理由,那么可以認為它是鍍金需求点楼。
第二項檢查也許更可靠:查看需求所附的滿意度/不滿意度評分扫尖。不滿意度,評分很低掠廓,說明該需求可能是鍍金的换怖。

8 需求蔓延

需求蔓延是指在大家認為需求已經(jīng)完成后,新需求又進入了需求規(guī)格說明書蟀瞧。
很自然沉颂,需求過程永遠不會結(jié)束。
但總存在一個項目階段悦污,在這個階段打算要開始構(gòu)建產(chǎn)品的工作铸屉。
在這個階段之后,發(fā)生的需求被視為需求蔓延切端。
質(zhì)量關(guān)在控制蔓延方面是有作用的彻坛。
你可以利用上下文模型中的數(shù)據(jù)瀏覽,決定需求是否超出范圍踏枣。
同時你也應該確保每項需求都包含有效的顧客滿意度/不滿意度評分昌屉。
這些評分告訴你,顧客認為該需求具有的價值茵瀑。
如果評分高间驮,那么蔓延的需求也許可以容忍。
如果需求蔓延到項目范圍之外或許產(chǎn)品的目標無關(guān)马昨,你就應該認真考慮一下竞帽,范圍是否正確。
產(chǎn)品的目標正確嗎偏陪?
符合實際嗎抢呆?
你需要仔細找出需求蔓延的根源。
也許范圍在一開始就說錯了笛谦,也許范圍應該變更抱虐。
需求蔓延的名聲不好,主要是因為他打亂了開發(fā)進度饥脑,增加了因此而導致提交產(chǎn)品的成本恳邀。
首先大多數(shù)需求蔓延都是因為一開始沒有正確的設(shè)計需求。
如果用戶和客戶沒有機會完整地參與需求過程灶轰,那么毫無疑問需求將是不完整的谣沸,幾乎可以肯定當提交日期臨近時需求會蔓延,用戶開始要求那些他們知道需要的功能笋颤。
還有一種蔓延產(chǎn)生的原因是最初的預算太低乳附,不符合實際情況内地。

9 實現(xiàn)質(zhì)量關(guān)
第一項決定是誰來實現(xiàn)質(zhì)量關(guān)。
建議從兩個人開始實現(xiàn)你的質(zhì)量關(guān)赋除,可能是需求分析師和一名測試人員阱缓。
這個質(zhì)量關(guān)是對需求的快速簡單的測試,而不是涉及半數(shù)團隊成員的辛苦過程举农。
比如需求分析師通過電子郵件將所有需求發(fā)送給質(zhì)量關(guān)守關(guān)人荆针,守關(guān)人將其中一些加入的校規(guī)和說明書中。
第二種方式是使用自動化的工具颁糟。有助于減少質(zhì)量關(guān)過程中人的干涉航背,某些需求收集工具可以完成初步的機械性的檢查,把所有的屬性都存在使用了正確的術(shù)語棱貌,提供了正確的標識符等玖媚。
伙伴相互檢查對方的輸出,在過程的早期發(fā)現(xiàn)錯誤婚脱。

第二個階段是同級復查最盅,由團隊中的其他人員正式復查每項需求。

第三個階段是團隊復查起惕,包括顧客和用戶。

第四個階段是管理者復查咏删,主要關(guān)注質(zhì)量關(guān)成功和失敗的總結(jié)惹想。

小婧的小結(jié):

目前我們的需求的解決方案確認方式是通過同級復查,然后再進行SRS編寫和提交需求評審/對接督函。
其實嘀粱,針對目前業(yè)務尚不是很復雜,BA不是很多的情況下是可行的辰狡。
但是如果隨著團隊的擴大锋叨,和產(chǎn)品復雜度的增加,確實需要對需求這部分的質(zhì)量關(guān)進行把關(guān)宛篇。
另外娃磺,本章說的其實是需求的質(zhì)量關(guān)而不是解決方案的質(zhì)量關(guān)。
在這個方面叫倍,感覺周圍人都做的很少偷卧。


第十四章 需求與迭代開發(fā)

我們的行業(yè)中有一項重要的進步,即開發(fā)者和業(yè)務人員共同承諾吆倦,盡一切努力听诸,盡可能的交付有價值的適當?shù)哪芄ぷ鞯漠a(chǎn)品。
讓我們看看這個承諾中“快”的部分蚕泽,許多組織機構(gòu)不是等待需求的所有細節(jié)都得到定義晌梨,而是更喜歡迭代完成這項業(yè)務活動。
這樣增量式交付發(fā)行版本直到解決方案被判定完成,這種迭代的方式意味著業(yè)務環(huán)境的開發(fā)環(huán)境中的關(guān)注點仔蝌、想法和變化更加同步泛领。目的是開發(fā)者更了解今天的業(yè)務問題耍群,工作的產(chǎn)品更適合今天的業(yè)務環(huán)境罢绽。

1 迭代的需求過程

圖片發(fā)自簡書App

2 如何編寫好用戶故事

要發(fā)現(xiàn)用戶故事,問這個問題:產(chǎn)品可以為用戶做些什么來滿足這個業(yè)務用例背后的業(yè)務意圖类早?要編寫真正的好故事豆混,你不能只是被動地聆聽業(yè)務利益相關(guān)者篓像,寫下他們認為最想要的東西。
你必須運用業(yè)務分析師的許多手藝皿伺,包括:創(chuàng)新员辩、思考問題本質(zhì)、業(yè)務事件的真正起源鸵鸥、在橫線上思考奠滑。

3 迭代需求的角色

你需要一名主題事務專家。
他是業(yè)務和工作問題的知識來源妒穴,提出業(yè)務要求也回答問題宋税,告訴你變更做出業(yè)務方面的選擇。
業(yè)務分析師是業(yè)務知識的有用來源讼油。
業(yè)務分析師既不屬于業(yè)務杰赛,也不屬于開發(fā)團隊。業(yè)務分析師中立的渠道矮台,他所受的訓練是觀察和發(fā)現(xiàn)業(yè)務需求乏屯,并將這些需求告訴開發(fā)者。
技術(shù)知識體現(xiàn)為開發(fā)者和系統(tǒng)架構(gòu)師測試員瘦赫,外部供應商的角色的某種組合辰晕。


第十五章 復用需求

每個人都想寫出別人能復用的組件,沒人想復用別人的組件确虱。
但是你如果要為新產(chǎn)品制定需求含友,那么開始時問一下:這些需求或相似的需求是否已經(jīng)寫過?
總有可能節(jié)省一些工作量蝉娜。

1 什么是復用需求唱较?

成功的復用始于一種組織文化。
這種文化有意識地鼓勵復用召川,而不是重新發(fā)明南缓。

圖片發(fā)自簡書App

在召開項目啟動會議時,就觸發(fā)關(guān)于復用的問題荧呐。

  • 項目的目標:組織機構(gòu)中是否存在其他項目與本項目一致汉形,或?qū)嶋H上包含相同的領(lǐng)域纸镊?
  • 客戶顧客和其他利益相關(guān)者:可以復用一份利益相關(guān)者名單,利益相關(guān)者圖個利益相關(guān)者分析表格嗎概疆?產(chǎn)品的用戶逗威,其他產(chǎn)品是否涉及相同的用戶,從而具有類似的易用性需求岔冀?
  • 強制的限制條件:限制條件是否已在其他項目中指定凯旭?是否有組織機構(gòu)的限制條件也適用于你的項目?
  • 命名標準核定義:你幾乎可以肯定利用原有詞匯表的一些部分
  • 相關(guān)事實與假定:注意最近一些項目的相關(guān)事實使套,對其他項目的假定也適用于本項目嗎罐呼?
  • 工作的范圍:你的項目很有可能成為組織機構(gòu)正在開發(fā)的其他項目的相鄰系統(tǒng),要利用其他工作上下文模型已經(jīng)建立好的接口侦高,考慮你的工作范圍是否其他項目已經(jīng)定了類似的業(yè)務時間
  • 業(yè)務模型:業(yè)務數(shù)據(jù)模型和數(shù)據(jù)字典嫉柴,是否有重疊或相關(guān)的項目,其業(yè)務數(shù)據(jù)模型可以作為你的起點奉呛。別太急著說現(xiàn)在的項目與之前的任何項目都不同计螺。
    是的,主題是不同瞧壮。
    但如果你不去看那些名字登馒,有多少底層的功能實際上是一樣的呢?
    啟動會上的利益相關(guān)者是很好的可復用組件的來源咆槽。

2 可復用需求的來源

非正式的有關(guān)經(jīng)驗的需求復用谊娇,當我們向同事詢問問題時,我們希望從他人的經(jīng)驗中學習罗晕,這樣不必從頭開始努力。一旦你知道了工作的上下文范圍赠堵,就可以尋找針對全部或部分小渊。
這一上下文的需求規(guī)格說明,將它們作為潛在的客戶有需求的來源茫叭。來源可以是任意一種同事的經(jīng)驗酬屉,也有的需求規(guī)格說明,模型當然還有書籍揍愁。

3 模式

模式是一種指南呐萨。
如果你試圖重復某項工作或近似地重復某項工作,它可以給出一種可遵循的形式莽囤。
但是從需求的角度來看谬擦,什么是模式呢?
是因為這個從某種邏輯功能組的一組需求模式朽缎,改進了需求規(guī)格說明書的精確性和完整性惨远。
注意模版的角色谜悟。
它是一個指南,而不是一種嚴格的指令或?qū)崿F(xiàn)北秽。
它可以復用葡幸,因為不需要重做實驗或發(fā)明,它是一組知識或經(jīng)驗可以進行調(diào)整和直接使用贺氓。

4 領(lǐng)域分析

可以把領(lǐng)域分析看作是非項目系統(tǒng)分析蔚叨,目的是為了了解有關(guān)的業(yè)務策略數(shù)據(jù)和功能,而不是構(gòu)建什么東西辙培。
在該領(lǐng)域所獲得的知識將用于該領(lǐng)域內(nèi)所有構(gòu)件產(chǎn)品的項目蔑水,最好是得到復用。
領(lǐng)域知識被發(fā)現(xiàn)被記錄并記錄下來后虏冻,就可以被任何構(gòu)建該領(lǐng)域產(chǎn)品的人使用肤粱。
領(lǐng)域知識適用于該領(lǐng)域的所有產(chǎn)品,要點不是重新發(fā)現(xiàn)已經(jīng)存在的知識厨相,而是使用真實的模型领曼。
領(lǐng)域分析是一項長期過任務,戰(zhàn)略分析上投資就像其他投資一樣蛮穿,投資將得到回報庶骄。

小婧的小結(jié):

領(lǐng)域建模和領(lǐng)域分析非常重要。
這些年我越發(fā)的體會到業(yè)務對于BA的重要性了践磅。
你也許有很多需求調(diào)研单刁、分析、開發(fā)的工具和技能府适,但是如果不了解業(yè)務就永遠無法深入核心羔飞。
與客戶在溝通上也會有很多二義性產(chǎn)生。
就最近檐春,我們聽客戶說“配建”逻淌,我們以為是“配件”。
這只是一個很簡單的例子疟暖,我們需要不斷的學習才能得到長遠的進步卡儒。


第十六章 溝通需求

在開發(fā)世界的一頭,你有業(yè)務俐巴;在另外一頭骨望,你有開發(fā)者和技術(shù)員。
他們已經(jīng)為這項業(yè)務做了一些工作欣舵。
對需求的要求是:它們傳遞的方式必須讓收到信息的人正確去讀它擎鸠、理解它、利用它缘圈。
“溝通需求”并不是必須要將需求寫成規(guī)格說明書糠亩,但是它們必須規(guī)范到一定的程度虐骑,讓所有涉及的利益相關(guān)者都能看清楚,并且同意你對需求的理解赎线。
讓需求正確廷没,不是讓開發(fā)變得更加官僚主義,而是讓它更加有效垂寥。

1 將潛在需求變成書面需求

在網(wǎng)羅需求或制作原型時颠黎,發(fā)現(xiàn)的需求并不總是準確的,因為它們只是關(guān)于需求的想法或意圖滞项,有時候是模糊的半成型的狭归。
而你得到的需求規(guī)格說明是產(chǎn)品構(gòu)建合同的基礎(chǔ)。
因此文判,它必須包含清晰过椎、完整、可測試的要求戏仓,說明必須構(gòu)建什么疚宇。
為了做到這一點,我們利用了規(guī)格說明書模板和需求項框架赏殃。
模板是一個拿來就可以用的需求規(guī)格說明編寫指南或檢查清單敷待。
需求項框架是針對單獨一項需求的容器,我們稱之為“原子需求”仁热。

2知識與規(guī)格說明書

在開始編寫需求榜揖,并將它們匯集成需求規(guī)格書之前,值得花一些時間來考慮需求過程中積累起來的知識抗蠢,比如下圖的需求知識模型举哟。

圖片發(fā)自簡書App

建議大部分的信息都可以包含在規(guī)格說明中。
知識模型中的累與其他類關(guān)聯(lián)迅矛,這些關(guān)聯(lián)表示的工作關(guān)系炎滞,未來模型的信息提供了額外的意義∥芷颍可以將這些知識模型看作是收集管理和追蹤的需求信息的一種抽象表示。
現(xiàn)在由你決定如何格式化并保存這些知識钠导。
你決定使用怎樣的自動化過程和手動過程震嫉,組合來記錄和追蹤這些內(nèi)容。
你也應該考慮哪類的知識的哪些部分放在哪些文檔中公布牡属。

3 需求規(guī)格說明書模板

需求規(guī)格說明書模板是“站在巨人的肩膀上”完成的票堵。
本書的作者從那些成功構(gòu)建的產(chǎn)品的需求規(guī)格說明中,借用了一些有用的元素逮栅,把這些最好的元素打包成一份可復用的模板悴势。
這個模板可以作為你的需求規(guī)格的基礎(chǔ)窗宇,這樣你也“站在了巨人的肩膀上”。

圖片發(fā)自簡書App
圖片發(fā)自簡書App

模板包括了五大部分內(nèi)容

  • 第一部分是項目驅(qū)動特纤。這些因素首先導致了項目的發(fā)生驅(qū)動军俊。包括了項目的目標,為什么你會參與該項目的需求收集捧存,以及誰想要這個產(chǎn)品粪躬。
  • 接下來是項目限制條件。它們將限制條件的需求和結(jié)果昔穴,限制條件在項目啟動階段寫進規(guī)格說明镰官,但可能有一些機制能夠更早地確定它們。
  • 接下來是產(chǎn)品的需求吗货。功能需求和非功能需求泳唠,每一項需求都以一定的詳細程度進行描述,這樣產(chǎn)品的構(gòu)建者就能精確地知道要構(gòu)建什么來滿足業(yè)務需要宙搬,要測試什么笨腥,來確保交付的產(chǎn)品滿足其需求。
  • 最后一部分是項目問題害淤。這些不是產(chǎn)品的需求扇雕,而是如果產(chǎn)品要件變成現(xiàn)實就必須要面對的問題。模板的這一部分也包括了“后續(xù)版本需求”窥摄,其中保存那些不打算在產(chǎn)品的首次發(fā)布中實現(xiàn)的需求镶奉,如果你采用迭代開發(fā)技術(shù),“后續(xù)版本需求”類似于開發(fā)列表崭放。

4 發(fā)現(xiàn)原子需求

原始功能需求和非功能需求應該寫的更正式采用一致的結(jié)構(gòu)哨苛,我們稱之為“原子需求”。
因為他們不需要分解币砂。
他們確實包含一些屬性建峭,就像真正的原子,包含一些亞原子粒子决摧。
但作為一個單元來處理更有用亿蒸,這些屬性構(gòu)成了完整的原子需求,最好是看成需求項框架掌桩,比如我們之前提到過的白雪卡边锁。

圖片發(fā)自簡書App

5 匯編需求規(guī)格說明

與其說需求規(guī)格說明書寫出來的,不如說是匯編的波岛。
顧客需求模板和白雪卡提供了方便的指導茅坛,說明了匯編哪些內(nèi)容才能得到完整的需求規(guī)格說明書。
模板指出了需求規(guī)格說明書要包含的主題则拷,白雪卡表明了每項源自需求需要包含的內(nèi)容贡蓖。

圖片發(fā)自簡書App

6 自動化的需求工具

如果項目中有多位需求分析師曹鸠,你會發(fā)現(xiàn)隨著工作的推進和需求數(shù)量的增加,自動化自動化的工具會帶來好處斥铺。
工具只是為你記錄需求彻桃。
在你決定使用某個工具之前,請將需求知識模型也可用的工具進行比較仅父,該工具能幫你記錄哪些知識叛薯,不同類知識之間的關(guān)系如何記錄,該工具能幫你維護哪些關(guān)系笙纤。
要知道你不太可能找到一個工具耗溜,能處理你的知識需求知識模型的方方面面。
但你肯定能找到一個盡可能接近的省容。
四處看看抖拴,你肯定會找到適合記錄供需求的工具組合。

7 項目問題

項目問題是需求活動中發(fā)現(xiàn)的一些關(guān)注點腥椒。
我們在需求規(guī)格說明書中加入項目問題是擔心如果不這樣做阿宅,就會遺漏它們。
但是如果你的組織機構(gòu)已經(jīng)有了過程或合適的文檔來記錄這些信息笼蛛,就不要將這些信息加到需求規(guī)格說明中洒放。

本章小結(jié)

無論何時,如果需求分析是有所發(fā)現(xiàn)滨砍,就寫下需求或部分需求往湿。
并非所有的需求都是同時完成的。
正確的編寫需求是很重要的惋戏。
一組好的需求能得到數(shù)倍的回報:
構(gòu)建工作更精確领追,維護成本更低,完成的產(chǎn)品更準確地反映了客戶的需要和想法响逢。

小婧的小結(jié):

需求規(guī)格說明其實一直都是我們BA最關(guān)注的內(nèi)容绒窑。
雖然很多的互聯(lián)網(wǎng)項目因為迭代周期短,不會形成大篇幅很正式的需求規(guī)格說明書(SRS)舔亭,但是不論你是用什么方式進行記錄些膨,比如在原型上記錄,或者采用白雪卡钦铺,或者采用用戶故事订雾。我覺得你需要“匯編需求規(guī)格說明”,也就是將你的產(chǎn)品中的所有需求及相關(guān)屬性進行匯編职抡。
這個是一項非常重要的組織過程資產(chǎn),為后期的開發(fā)误甚、測試缚甩、維護谱净、使用、優(yōu)化都提供了依據(jù)擅威。


第十七章 需求完整性

在需求過程的某個階段壕探,你需要發(fā)布全部或部分需求規(guī)格說明。
因為其他人如開發(fā)者郊丛、測試者李请、市場人員及供應商需要它。
待發(fā)布的需求規(guī)格說明不一定包括全部需求厉熟。
在發(fā)布之前导盅,需要確保相對于它的目的它是完整的。
這里使用術(shù)語“規(guī)格說明”來表示你擁有的任何形式的需求組合揍瑟,不一定是正式的書面規(guī)格需求說明書白翻,甚至不一定是正式的。
復查需求規(guī)格說明是否完整绢片,可以考慮如下內(nèi)容:

  • 確定是否遺漏了需求
  • 排列需求優(yōu)先級滤馍,這樣構(gòu)建者能理解需求的重要性和緊急性
  • 檢查需求之間的沖突,這會阻礙一項或多項其他需求的實現(xiàn)
  • 預估構(gòu)建的成本底循,物評估項目所面臨的風險復查的過程是迭代式的巢株,尋找問題或遺漏,修正問題熙涤,這可能意味著引入新問題阁苞。
    需要讓這個過程迭代一次或兩次,確保規(guī)格說明書中沒有漏洞灭袁。

1 審查

有一種相當有效的規(guī)格說明審查方式猬错,它是一個正式的過程,稱為Fagan審查茸歧,具體步驟如下:

  • 審查過程開始時倦炒,有一名協(xié)調(diào)人確定要審查的材料和審查者
  • 審查者收到被審查的文檔的概要,他們大概有一天的時間來研究這些材料
  • 審查會議限制在兩個小時以內(nèi)软瞎,利用以前發(fā)現(xiàn)的問題的檢查清單來分析文檔
  • 如果發(fā)現(xiàn)新錯誤逢唤,不在清單上的錯誤,就會更新清單
  • 作者對文檔進行返工協(xié)調(diào)人涤浇,確保所有的錯誤已經(jīng)消除鳖藕,如有必要協(xié)調(diào)人會安排跟進的審查

2 發(fā)現(xiàn)遺漏的需求

功能需求應該足夠完成每個用例的工作。
為了檢查這一點只锭,假設(shè)你就是這個產(chǎn)品著恩,把每個產(chǎn)品用例推演一遍。
如果做了需求要求的所有事情,是否能夠得到用力的成果喉誊,用戶是否滿意地認為產(chǎn)品會完成他們的工作要求邀摆。
尋找產(chǎn)品必須處理的異常情況,復查場景伍茄。
針對每一步確定是否可能產(chǎn)生異常栋盹,或者是否有異常組織用戶到達這一步。
針對非功能需求類型檢查每個產(chǎn)品用例敷矫,是否具備了它需要的和合適該類用例的所有非功能需求例获。

3 發(fā)現(xiàn)所有業(yè)務用例

針對每個業(yè)務事件,你確定業(yè)務的響應曹仗,并確定相應的哪些部分需要由產(chǎn)品來完成榨汤。
建議你每次收集一個產(chǎn)品用例的需求,持續(xù)到涵蓋所有業(yè)務事件為止整葡。

4 排l需求優(yōu)先級

確定優(yōu)先級很復雜件余,因為他們涉及不同的因素,而且這些因素彼此之間常常產(chǎn)生沖突遭居。
另外由于不同的利益相關(guān)者可能有不同的目的啼器,對優(yōu)先級達成一致意見可能比較困難。
雖然困難俱萍,這項工作遲早要做端壳,越早越好,越早排隊優(yōu)先級就越容易枪蘑。
每項需求都應該包含:顧客滿意度和顧客不滿意度評分损谦。
這些評分幫助顧客考慮單向需求的相對價值,并對它們排列優(yōu)先級岳颇。
影響優(yōu)先級的因素有

  • 實現(xiàn)的成本
  • 對顧客或客戶的價值
  • 產(chǎn)品所需的時間是技術(shù)實現(xiàn)的容易程度
  • 業(yè)務或組織機構(gòu)實現(xiàn)的容易程度
  • 對業(yè)務的好處
  • 遵守法律的要求

何時確定優(yōu)先級照捡?
一旦存在兩項任務即可作出選擇。
讓需求知識變得越可視话侧,就越有機會進行不盲目的選擇栗精,并幫助他人進行選擇。
不斷排列優(yōu)先級的一部分瞻鹏,原因是期望值管理悲立。
利益相關(guān)者常常假定術(shù)語“需求“,意味著這些功能肯定會實現(xiàn)新博。
需求實際上是一些期望和愿望薪夕,需要清楚地了解他們,以決定是否實現(xiàn)它們赫悄。
如果你在項目過程中一直不斷地排列優(yōu)先級原献,人們就能夠接受這種折中馏慨,而不會感覺到欺騙。
排列優(yōu)先級讓利益相關(guān)者準備好接受一個事實姑隅,也就是你不能實現(xiàn)所有的需求熏纯。

小婧的小結(jié):

需求的遺漏一直是一個大難題。
而需求的遺漏也是造成需求變更的一個非常常見的原因粤策。
有的時候是BA覺得這“顯而易見”,不需要進行描述误窖。卻沒有想到會產(chǎn)生二義性叮盘。
我認為復查等方式是非常有必要的。
特別是找別人來復查霹俺。
當大家開始針對一段需求的描述進行討論時柔吼,二義性就產(chǎn)生了。
我們必須保證需求是清晰丙唧、明確愈魏、可測試、完整想际,才能保證產(chǎn)品的正確性培漏。
另外,關(guān)于需求的優(yōu)先級我覺得有多種評分方式胡本。
現(xiàn)在簡單的高中低已經(jīng)完全沒有辦法滿足我們?nèi)找鎻碗s的產(chǎn)品的需要了牌柄。

小婧是一名行走在產(chǎn)品路上的資深業(yè)務分析師(BA),如果想與我同行侧甫,就請關(guān)注我吧珊佣!

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市披粟,隨后出現(xiàn)的幾起案子咒锻,更是在濱河造成了極大的恐慌,老刑警劉巖守屉,帶你破解...
    沈念sama閱讀 211,290評論 6 491
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件惑艇,死亡現(xiàn)場離奇詭異,居然都是意外死亡胸梆,警方通過查閱死者的電腦和手機敦捧,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,107評論 2 385
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來碰镜,“玉大人兢卵,你說我怎么就攤上這事⌒饔保” “怎么了秽荤?”我有些...
    開封第一講書人閱讀 156,872評論 0 347
  • 文/不壞的土叔 我叫張陵甜奄,是天一觀的道長。 經(jīng)常有香客問我窃款,道長课兄,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,415評論 1 283
  • 正文 為了忘掉前任晨继,我火速辦了婚禮烟阐,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘紊扬。我一直安慰自己蜒茄,他們只是感情好,可當我...
    茶點故事閱讀 65,453評論 6 385
  • 文/花漫 我一把揭開白布餐屎。 她就那樣靜靜地躺著檀葛,像睡著了一般。 火紅的嫁衣襯著肌膚如雪腹缩。 梳的紋絲不亂的頭發(fā)上屿聋,一...
    開封第一講書人閱讀 49,784評論 1 290
  • 那天,我揣著相機與錄音藏鹊,去河邊找鬼润讥。 笑死,一個胖子當著我的面吹牛盘寡,可吹牛的內(nèi)容都是我干的象对。 我是一名探鬼主播,決...
    沈念sama閱讀 38,927評論 3 406
  • 文/蒼蘭香墨 我猛地睜開眼宴抚,長吁一口氣:“原來是場噩夢啊……” “哼勒魔!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起菇曲,我...
    開封第一講書人閱讀 37,691評論 0 266
  • 序言:老撾萬榮一對情侶失蹤冠绢,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后常潮,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體弟胀,經(jīng)...
    沈念sama閱讀 44,137評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,472評論 2 326
  • 正文 我和宋清朗相戀三年喊式,在試婚紗的時候發(fā)現(xiàn)自己被綠了孵户。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,622評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡岔留,死狀恐怖夏哭,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情献联,我是刑警寧澤竖配,帶...
    沈念sama閱讀 34,289評論 4 329
  • 正文 年R本政府宣布何址,位于F島的核電站,受9級特大地震影響进胯,放射性物質(zhì)發(fā)生泄漏用爪。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 39,887評論 3 312
  • 文/蒙蒙 一胁镐、第九天 我趴在偏房一處隱蔽的房頂上張望偎血。 院中可真熱鬧,春花似錦盯漂、人聲如沸烁巫。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,741評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至磁餐,卻和暖如春违崇,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背诊霹。 一陣腳步聲響...
    開封第一講書人閱讀 31,977評論 1 265
  • 我被黑心中介騙來泰國打工羞延, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人脾还。 一個月前我還...
    沈念sama閱讀 46,316評論 2 360
  • 正文 我出身青樓伴箩,卻偏偏與公主長得像,于是被迫代替她去往敵國和親鄙漏。 傳聞我的和親對象是個殘疾皇子嗤谚,可洞房花燭夜當晚...
    茶點故事閱讀 43,490評論 2 348

推薦閱讀更多精彩內(nèi)容

  • 第十二章 驗收標準和理由 我們這里所說的驗收意味著:解決方案完全滿足或符合需求。也就是說怔蚌,解決方案準確的實現(xiàn)了需求...
    顏小婧閱讀 932評論 2 11
  • Android 自定義View的各種姿勢1 Activity的顯示之ViewRootImpl詳解 Activity...
    passiontim閱讀 171,756評論 25 707
  • 辦公室雜物 辦公室的抽屜里放滿了文件巩步,書和雜物。 書有自己買的專業(yè)書籍桦踊,但更多是單位發(fā)的椅野。信貸管理辦法,安全保密手...
    莫莫momo閱讀 163評論 0 0
  • 你的朋友,就是你的鏡子杖狼,你在鏡子中炼蛤,照出你在和他(她)相遇時候的自己。因為靈魂有相似蝶涩,所以才互相吸引鲸湃。 有些人走著...
    鮒魚閱讀 343評論 0 0
  • 北上廣的房價赠涮,相信大家都有所了解,普通的工薪階層能依靠自己的能力在北上廣等大城市買房子的暗挑,又能有多少笋除。如果有能力,...
    無邪居閱讀 413評論 0 0